In about six weeks time developers from all over the world will convene
in Prague for the 2005 edition of the
Firebird Conference. This year’s conference has an even greater
abundance of speakers and topics than the previous editions of the event.
The various
tracks on the conference will cover Firebird itself, development
languages and solution stacks, development tools and issues and
applications. And, of course, it is a great opportunity to meet the
community.
Despite being one of the most popular open source databases, Firebird may
be somewhat unfamiliar to the regular OSNews readership. Just in case you
did not know already, let me introduce Firebird to you: Firebird is an open source database
with roots in Borland’s Interbase, which itself has roots going back 20
years.
Because of the bundling with Delphi and
Kylix, Firebird is very popular with the approximately 1 million Delphi
developers around the world. In the last decade tens of thousands C/S
applications have been created and the Firebird installed base is estimated
at just under 2 million deployments (and about 3 million if you include
legacy Interbase installations). Although the bulk of the deployments is for
mid-market use, a significant share is for “enterprise level” usage.
Firebird is at the core of about one-third of financial applications in the
former Soviet Union and SAS, the world’s
largest privately held software firm, has chosen Firebird to drive its
high-end business analytics systems.
The Firebird core track of the conference will focus on new developments,
development process and roadmap, and give a view of the database internals.
Dmitry
Yemanov, the release manager for Firebird 1.5 and Firebird 2.0, will
talk about the current and future releases, and give an overview of how
Firebird works “under the hood”. Jim
Starkey, the original author of Firebird, will talk about the Vulcan
project, a wholesale rewrite and clean-up of the code base, optimised for
modern SMP hardware. Paul Ruizendaal, main driver of the Fyracle project,
will talk about Firebird’s oracle compatibility mode and Arno Brinkman will
explain how the optimiser works, a topic that always draws large crowds at
Firebird conferences. Others will speak about the Firebird Q&A process,
about performance testing and new security features.
The languages track covers the various solution stacks that are commonly
used with Firebird: Delphi, Java, .Net and PHP. Many sessions cover
developing with Delphi, or more correctly with Object Pascal: the original
Delphi tool has been joined with a Linux version by Borland, Kylix, and by a
cross-platform open source edition, FreePascal/Lazarus.
Delphi based talks include Jason Warton on his famous IBObjects class library, Fikret
Hasovic, editor of the Firebird News,
on n-tier programming and Kim Madsen on the kbmMW application server. Java
is also well covered with Roman Rokyttskyy, project lead for the Firebird JCA/JDBC
driver, talking about the new 2.0 release and Eugeny Putilin talking
about stored procedures and trigger bodies written in Java. Programming in
PHP will be covered from various angles, including Lester Caine’s ever
popular how-to talks.
General development issues are covered in the tools, tips and tricks
track. Milan Babushkov will speak about FlameRobin, the emerging project admin
tool (Firebird has always been surrounded by a rich cottage industry of tool
vendors, so for along time there was not a tool by the Firebird project
itself). There are talks about development libraries, such as
InstantObjects, FireQ and FIBPlus, and about application optimization.
Carlos Cantu, author of the leading Firebird
book in Brazil, will talk about advanced Firebird programming with PSQL,
stored procedures and events. Other topics that are covered in this track
are migration, conversion, internationalization, audit trails and, last but
not least, replication.
This year’s applications track will prove to be very interesting. Bill
Oliver and Tom Cole will speak about SAS and their choice for Firebird
inside of their enterprise level business analytics software. Jeanot
Bijpost, winner of the 2004
RAD Race, will speak about model driven development and the innovative
Cathedron application builder. ERP applications will be covered from several
angles: the Cathedron system has been used to build a large, distributed ERP
system, the oracle-mode talk will cover running Compiere on top of Firebird, and Claus
Heeg will speak about building web ERP systems using Firebird and
ColdFusion. An entirely different application class is covered in Vince
Duggan’s talk about using Firebird to implement a fingerprint recognition
system
The best of any conference is always the people. This edition of the
Firebird conference will have participants from all five continents, both
speakers and visitors. Many of the project’s core developers and
personalities will attend, so the conference will be a hub for exchanging
views and experiences. For every Firebird user, it is an ideal opportunity
to give feedback to the developers and to potentially influence the Firebird
roadmap.
Looking forward to meeting you in Prague this November!
Paul Richter
If you would like to see your thoughts or experiences with technology published, please consider writing an article for OSNews.
I thought firebird was a web browser..
Firebird is the best open source relational database for cross-platform development. Not sure how it compares with postgresql now that postgresql is avaiable in windows as well. Any benchmark available to compared between the two?
It would indeed be interesting to benchmark the various OS databases: Firebird, Postgres, and MySQL.
yes and whats really interesting is that firebird comes in several flavours:
1) The superserver is a multithreaded design (much like Mysql) and this is great for raw speed (threads typically being a lot faster to create and considerably more lightweight on memory than seperate processes)
2) The Classic Server. This is a mutli process design like Postgres
3) Embedded – this is a dll or shared object instead of a daemon that you can embed in any application (much like Sqlite)
4) Vulcan – Teh next generation firebird that contains a generic engine that can be any of the above!
I would expect the superserver to be on a par with Mysql for performance but faster than postgres especially with loads of connections due to threads massively outperforming mutliple processes when connection count is high.
I don’t know if benchmarks would be interesting at all since speed is the one and only strength of MySQL. Fetcher completeness in respect to the SQL standard should be an issue and that’s where MySQL sucks. They have a special kind of fetcher creep, the fetcher creeps from one todo list to the next since they can’t implement it.
“speed is the one and only strength of MySQL”
Only if you turn off transactions in mySQL. Using InnoDB engine with mySQL is dog slow. We have done lots of benchmarks of Firebird and mySQL (InnoDB) and Firebird wins out easily. Only time I have ever seen mySQL beat Firebird is when mySQL is using non-transactal myISAM, and the queries are very simple (no joins etc…), but why test this way? Only the simplest of apps would not need transactions or joins.
I really like Firebird’s oracle-mode. Our company is selling a library management system written in Oracle’s Dev2000. Getting Oracle sold and installed is always a major hassle. With the Oracle-mode I can concentrate on our own stuff.
Can you tell us more about this oracle-mode? The docs or url? I am interested. Thank you very much.
Oh, never mind.
A little googling found http://www.janus-software.com/fb_fyracle.html.
Seems interesting. Might port our oracle apps to firebird.
“Firebird is the best open source relational database for cross-platform development. Not sure how it compares with postgresql now that postgresql is avaiable in windows as well.”
Well, you shouldn’t say X is the best (or better than Y) if you don’t know about Y. 🙂
But I’ve read that Postgres’ speed is not so great on Windows. Probably because the Win32 port is new and not much optimization has been done to it.
Haven’t seen a major release of Firebird for quite a while now though…
anybody knows? he’s a talented developer and used to hack on FB about 2-4 years ago.
AFAIK he is busy working on FB stuff for BroadView Software, a Canadian company with big investment into Firebird, and one from big Firebird & Foundation sponsors. I suppose that he would show up on conference along with others from BroadView.
I’m not interested in how many transactions per second one is over the other (firebird v postgres). I use firebird. all i care for is real MVCC and integrity which both provide. the winner for me is that I can embed firebird by just dropping a dll into the directory my app is in… and i can grow it from embedding to a full server without any pains OR a single change to my code…
choosing either firebird or postgress is a winning scenario for most anyone…. having real MVCC in two free products is just awesome.
Is there MVCC that is “not real”?
Mysql+InnoDB also offers MVCC (I believe the “real” one too).
[i]I don’t know if benchmarks would be interesting at all since speed is the one and only strength of MySQL. Fetcher completeness in respect to the SQL standard should be an issue and that’s where MySQL sucks. They have a special kind of fetcher creep, the fetcher creeps from one todo list to the next since they can’t implement it.[i]
I’m not a big fan of MySQL either, but the upcoming MySQL 5.0 (now beta or just recently RC, I believe) is not so bad. You get strict mode (where MySQL will reject instead of silently accepting/truncating bad dates or out-of-bound strings/numbers). You also get views, triggers, procedural languages, etc. IIRC, MySQL AB has pledged that they will implement “all” parts of the SQL standard.
As long as you don’t mind paying for it, or open sourcing any application that touches it.
I’m referring to the fact that mySQL 5 no longer has an LGPL driver.
Yes, what happened to him?
Firebird is not that great…
1. Has weird sql dialects
2. Limited number of built in functions
3. Because of small amount of built in functions, you must resort to UDFs that can be flakey.
3.No temp tables at all
4.No tablespaces
5.You can use all SQL in stored procs(except via EXECUTE command)
6. Transactions are stored in the same file as the DB, which results in huge file growth.
7. Because there is no seperate transaction table, you can’t do point in time recovery.
8. Only one stored proc language
9. Development is pond water slow…
10. The developer community at times can be cranky(and that is putting it mildly)..
11. Can’t do cross server/database queries/joins
12. DBs are referenced by file name and path
13. Password security is limited and weak
When you look close it’s a very limited database and these are just a small number of the problems with it.
If you need somthing that can be embedded, then Firebird is a good choice, however it is not ready for the Enterprise yet. Postgresql is a much better choice IMHO.
Most of your points are valid specially numbers 6 and 9.
But some others are kinda innacurated like
Number 1.- I think the dialect is plaint simple.
Number 3.- Is coming in firebird 2 before at the end of this year.
Number 4.- Is that really necesary?
Number 12.- There are alias for them so you dont have to use the path.
number 13.- Your DB will be as secure as you secure your server.
And you forgot one, the documentation is to poor.
But mean while PG in windows keep being to damn slow I will have no choice.
1. It’s historical, and all DB products have their SQL quirks don’t they?
2 & 3 should not be a problem if FB comes prepackaged with the frequently used functions.
8. Most other SQL DBs have one stored procedure language either, and that doesn’t seem to be too crippling. But I admit, being able to use Ruby (e.g. in Postgre) or .NET (e.g. in SQL Server) should be fun and joyful compared to those weird, COBOL-like procedure languages.
9 & 10. This is one of the main problem with FB.
12. Aliases.
—
My main problem with FB is that DDL (CREATE TABLE, ALTER TABLE, DROP TABLE, etc) are weird and not really transactional. You need to COMMIT after each DDL. Well sometimes there are use cases where I need DDL to be inside a transaction so it is rollback-able if things go wrong.
—
But as long as there’s no embedded Postgres (which will be the case for a long time) FB will have its niche. SQLite doesn’t come close in feature set.
> 1. Has weird sql dialects
The only quirky thing about Firebird is the Stored Proc language – this is NOT part of the SQL dialect, and all comparable products have similar quirks (e.g. T-SQL in SQL Server and Oracle’s PLSQL which is basically ADA.)
> 2. Limited number of built in functions
> 3. Because of small amount of built in functions,
> you must resort to UDFs that can be flakey.
UDF, UDF, UDF. Regression testing. I have written countless UDF functions for Interbase, and it aint hard. In fact, it is so easy as to be stupidly easy.
If you test your code, you have nothing to worry about!!
> 3.No temp tables at all
Who needs temp tables? What are they used for?
create procedure NOTEMPTABLENEEDED
returns (id integer, text varchar (20), num integer)
declare variable t1 varchar (7);
declare variable t2 varchar (10);
begin
for select id, text1, text2, num
from atable
into :id, :t1, :t2, :num do
begin
text = :t1 || :t2;
suspend;
end
end
then:
select * from NOTEMPTABLENEEDED;
TADA! No temp table needed.
> 4.No tablespaces
Explain why that is a problem?
> 5.You can use all SQL in stored procs(except via
> EXECUTE command)
That doesn’t even make any sense. You can call “execute procedure” or you can call “select whatever from…” depending on whether the SP returns one result or multiple lines. What is the problem with that?
> 6. Transactions are stored in the same file as the
> DB, which results in huge file growth.
Which can be removed instantly if you back up and restore the database… you do backup your database periodically, dont you?
gbak -b mydatabase.gdb mydatabase.gbk -user XXX – pass YYY
gbak -r mydatabase.gbk mydatabase.gdb -user XXX – pass YYY
Will recover all surplus space.
> 7. Because there is no seperate transaction table,
> you can’t do point in time recovery.
And why is that an issue? Do regular backups (which can be done inline whilst the database is being used and accessed) and this is purely moot.
> 8. Only one stored proc language
LOL. SQL Server 7 and 2000 only had one too.
> 9. Development is pond water slow…
Rather it was stable.
> 10. The developer community at times can be cranky
> (and that is putting it mildly)..
Because they complained when someone stole their name? What would you do?
> 11. Can’t do cross server/database queries/joins
Good. Maybe then people will design better systems.
> 12. DBs are referenced by file name and path
Un true. Interbase, and by virtue Firebird up to at least 1.5, supports 4 different access methods. Local (by path), TCP/IP, SPX/IPX and Named Pipe.
Equally, you can pump either of the following paths into a Windows Firebird TCP-IP connection:
127.0.0.1:c:mydatadata.gdb
127.0.0.1:/mydata/data.gdb
either will work.
> 13. Password security is limited and weak
Why? How secure is your server? You do not have to use the default admin user, in fact we used to delete that user when I worked for a company that used FB1.5 a while back.
> When you look close it’s a very limited database and
> these are just a small number of the problems with
> it.
You can always bet this post will arrive on OS News when there is a Firebird story. YAWN!
> If you need somthing that can be embedded, then
> Firebird is a good choice, however it is not ready
> for the Enterprise yet. Postgresql is a much better
> choice IMHO.
Oh crap, well we better let all out customers know…. Seriously, you are spouting complete rubbish.
>but faster than postgres especially with loads of >connections due to threads massively outperforming >mutliple processes when connection count is high.
This is totally not true. You are forgetting that the Postgresql process is created at connection time and has nothing to do with the speed of queries.
Also with Postgres (and classic FB) one errant thread wont take down the whole server.(it will in SS firebird)
You also seem to be forgetting that with lots of threads you get lots of context swaps which can hurt performance.
The processes used by PG and FB classic will handle more connections better than threads, espesially on Unix systems.
I can tell you this for sure, when the postgres.conf file is setup properly it is just as fast if not faster than firebird.
Multiple process DBs like Postgres are not scalable when compared to threading ones like Firebird and mysql.
Threaded ones can easily support 10x and even 20x the no of connections of a process based one (due to lighter memory requirements).
The cache is shared amongst all threads hence hotter cache and faster queries.
So I am right – threaded RDBMS easily out perform process based ones when the no of conections exceed about a dozen.
I believe he got pissed off at Jim Starkey.
Jim can be a huge ahole, actually he is most of the time.
<Oh crap, well we better let all out customers know…. Seriously, you are spouting complete rubbish.>
I don’t think so, I have used Firebird and Postgresql and Postgres is the better database.
<That doesn’t even make any sense. You can call “execute procedure” or you can call “select whatever from…” depending on whether the SP returns one result or multiple lines. What is the problem with that?>
It makes perfect sense, because in Postgresql stored procs you dont’ have to use EXECUTE, you can simply call CREATE USER or CREATE DATABASE or anything you want, no need to use execute at all, and that’s because Postgresql only has one SQL, Firebird has PSQL, DSQL and one other one, you can only use PSQL in procs, if you want to execute DDL you must use execute.
um..wrong. The only time you use execute procedure is when you want to *run* a procedure. As previously noted, you don’t even need to do that if your procedure calls suspend after it has filled the returned variables – you can just call it as if it was a built in function via select.
> 12. DBs are referenced by file name and path
Un true. Interbase, and by virtue Firebird up to at least 1.5, supports 4 different access methods. Local (by path), TCP/IP, SPX/IPX and Named Pipe. >
true true true, using TCP/IP you must use like so:
192.168.12.13:/opt/data/mytestdb.fdb NOTE THE PATH is still used, no mater what transport you use the path must be included.
Even with aliases you must manually build them on the server side. You don’t have to do any of this with Postgresql, the more you use PG, the more you wonder why you used to like FB.
PG keeps a system table called pg_database and it contains info on all databases created. With PG all you need is the name, the rest is taken care of.
As far a security goes Postgres has built in SSL support, encrypted/md5 passwords and access control via host/IP.
Also as far win32 speed goes, I ported a Firebird app to Postgresql and we can’t tell the difference, it was fast before and it is fast now with Postgres.
Postgres out of the box is not optimized for high end corp systems because most people don’t have a 3.5gzh Xeon, so you have to tweak the conf file a bit to get really good performance, it’s just part of the flexiblitiy.
>Even with aliases you must manually build them on the
> server side. You don’t have to do any of this with
> Postgresql, the more you use PG, the more you wonder
> why you used to like FB.
> PG keeps a system table called pg_database and it
> contains info on all databases created. With PG all you
> need is the name, the rest is taken care of.
I prefer the FB way, it’s far better than central dictionary in system table. I frequently have many copies of the same database with different data and structures (some apps. work that way, sometimes is just for development). Handling that in PG is very painful (each must have different name etc.), while in FB I don’t even think about it, just type in the right path and go. When I need db location independence (only on deployment), I can set up aliases, which is very simple. The fact that under FB, databases are selfcontained, easily transportable beasts is a great advantage over such behemoths like PG, that have many unnecessary layers of complexity, that add to the cost of db management. While PG has some nice features, it carry too many “database stone age” design flaws.
> As far a security goes Postgres has built in SSL
> support, encrypted/md5 passwords and access control
> via host/IP.
I don’t need that at the db server, because I can easily do that by other means when necessary (ZeBeDe etc.), so my server will not carry along a dead weight when I don’t need it.
How many people will still come because they think it’s about Firefox.