Slashdot Mirror
Firebird Goes Gold
An Anonymous Coward writes: "A lot has happened since Borland open
sourced their Interbase database.
Borland has since come out with a new closed source version of Interbase,
forcing the Phoenix group to fork the codebase, calling their new database Firebird. Over the past month they have come out with Firebird version 1.0 for various UNIX variants, Windows, and Mac OS X and are now working on moving the code base from C to C++. A great description of Firebird is found here. To show
your support, order Firebird on CD."
I notice some stories, like this one, are posted in areas that I should be seeing on my custom slashdot homepage, but never show up unless I view the "older stuff" link. And usually they have a very low number of comments, so I'm guessing not too many other readers are seeing them either.
What is going on?
"And like that
So far I've got the database installed, and found I needed a tool to administer it enough to change the password, did that... now what?
--Mike--
I keep saying it. He doesn't listen. Most of Slashdot's performance issues relate to its use of MySql. Listen up! MySql is just a indexed file manager with a SQL front-end. There's more to RDBMS than support a relational language! Get a real DBMS already! Give Firebird a try, or I'll tell Kathleen about the dead pelican!
Also, one of the few things Access is good for (aside from producing forehead-shaped wall divots) is learning SQL. You can start out composing a query in the query-by-example form, then switch to the SQL view, tweak it there, switch back... Downside is that you will then have to unlearn the sillier features of Access's SQL implementation. Somebody wasn't paying attention in Set Theory 101!
You can also use Access as a front end for Interbase/Firebird. Not that you should....
Hejsan Lasse! :)
Disclaimer: I have used MySQL (a little) and PgSQL (a lot more) but not FB (nor IB), so I'm just repeating what I have read somewhere.
My impression is that FB and PgSQL are quite similar. Both have multiversion cuncurrency control, ACID compliancy, stored procedures, triggers, referential integrity and a lot of other cool stuff. Both support large subsets of SQL92, outer joins, subselects etc.
PgSQL, on one hand, is a classical unix style forking multi-process server, whereas FB has both a multi-process and a multithreaded model. The advantage of the multithreaded model is of course a shared cache, but FB:s threaded version doesn't work on multiprocessor machines. Anyway, on unix at least PgSQL uses posix (or was it sysv?) shm to get a shared cache. On the other hand, the windows version of PgSQL is a cygwin hack, whereas FB has a native win version.
MySQL, on the other hand, does not (currently) play in the same league. Yes, with simple queries and low concurrency (albeit a common situation) it probably smokes both FB and PgSQL speedwise. IMHO MySQL suffers from limited SQL support, table level locking and lack of ACID properties. For more info check out this page which describes some of the problems with MySQL in more detail (and of course there is a super-long flamewar at the end too...). Anyway, MySQL 4 (alpha) apparently supports more SQL constructs, and new tablehandlers give it row-level locking (or even multiversion concurrency control) and at least some limited ACID capabilities, so the gap between MySQL and PgSQL/FB appears to be shrinking fast..
And then there is of course SAPDB, which appears to be very impressive according to the few people who have tried it.
In the end, I think all of them are excellent (with some reservations towards MySQL and SAPDB). And of course they are all free (duh!). I'd say FB has better windows support than PgSQL and certainly has better delphi drivers, whereas PgSQL would be better on a multiprocessor unix/linux box.
And no, the answer is not "features".
Here's the nasty truth: for most large-scale applications, MySQL is very slow. Despite its SQL front end, MySQL is just a simple indexed file engine. Now, there are a lot of applications where such an engine is more efficient than a relational engine. That would include a lot of low-end databases of the type you see on web sites that serve a few thousand hits per day. Naturally, the implementors of those web sites find that MySQL meets their needs better than fancier software. But to generalize from that to the believe that MySQL is the fastest engine for all applications is very naive.
I don't know of any other web site of Slashdot's scale (measured in daily hits) that uses MySQL to serve its content. (Before you start citing examples, note that Slashdot's daily hit count is in the millions.) The engine just isn't up to it. Rob gets around this by throwing hardware at the problem, and by generating static HTML files for popular content -- content that on any other high-end web site would be generated by a dynamic retrieval.
But I hope you're not trying to argue that a simple data access technique like the one MySQL uses can scale indefinately! Just how far it can scale is a matter for someone who strong in database theory than I am. But it seems obvious to me that you'll reach the limitations pretty soon.
Now, when you compare MySQL with more advanced DBMSs, you can't just focus on one difference like data integrity. There are a lot of differences -- query optimization, obscure techniques for speeding up file I/O, etc., etc. Nor can you blame any one of these difference for the massive overhead of running high-end DBMSs like Oracle.
Which brings us back to the actual topic: Firebird. Which is just a fork of Interbase. Which is almost as different from Oracle as MySQL is. Which is why Interbase has an excellent reputation as an engine that supports high performance with low overhead.
If you're totally ignorant of basic computer science.