Slashdot Mirror
Firebird Relational Database 1.5 Final Out
firebirdy writes "The Firebird Project is pleased to announce that the v1.5 release of the Firebird database engine is now available for immediate download. The v1.5 release represents a major upgrade to the engine, which has been developed by an independent team of voluntary developers from the InterBase(tm) source code that was released by Borland under the InterBase Public License v.1.0 on 25 July 2000. Development on the Firebird 2 codebase began early in Firebird 1 development, with the porting of the Firebird 1 C code to C++ and the first major code-cleaning. Firebird 1.5 is the first release of the Firebird 2 codebase. Install packages are currently only available for Windows and Linux but other platforms should follow shortly." This product is not to be confused with newly renamed Firefox web browser, which was also called Firebird for some time.
It's not a matter of ease, they were around for a lot longer and had the name long before Mozilla co-opted it.
Finkployd
I tried building the Firebird code a few months ago, and found out that step 1 is...
...start with a running version of Firebird!
Bootstrapping might seem like a K00l trick, but there is something uncomfortable about self-referential build procedures (not to mention that it was a pain in the ass to find a preexisting version of Firebird to run).
Gimme a pile of c/cpp & h files and let me build it from scratch, dammit!
Is that possible today? Dunno...the build guide appears to be still under construction.
On the other hand, I hated having to administer that hell-pit of a server so badly that I wrote a migration program to transfer entire databases from Firebird to PostgreSQL. I can't describe how happy I was to switch a fairly large online store's backend to a modern platform.
Dewey, what part of this looks like authorities should be involved?
I used interbase at a previous shop (had to, the "fearless leader" was a borland guy through and through).
I can say that it seemed to handle fine, the server never crashed, there was never a corruption etc - and this was for fairly large databases as well (million+ records etc)..
Firebird I'm sure improves even further on it, the only problem I had with it was it's horrid horrid gui interface(s).
Wrong. This is a fine database that was built from the once open-sourced Borland Interbase. Anybody working with free databases should know it (people who are comparing it to MySql: is mysql a *real*, relational, transactional database server? stored procedures? triggers? foreign keys? )
Related to the naming issue: the mozilla people choosed a name that was already taken by another project, they changed their name now, and that's it...
Why do we ask companies to GPL their aging products and then ask if anyone cares?
This RDBMS is a viable peer to PostgreSQL. It has many features that MySQL does not have.
Just the other day, there was a good article about this database.
I'm also an Oracle guy. I find MySQL loathesome and inadquate for all buy toy-level applications. I see Firebird and PostgreSQL both as viable midrange solutions. I think they each could work in settings were you aren't really stressing the newest features of Oracle, but want "standard" RDBMS functionality. Both have stored procedures, triggers, and some kinds of subqueries (at least in the WHERE clause -- oracle has them also in the from clause and even in the SELECT clause).
I think you'll find that materialized views, at least as far as doing refresh-on-commit and query rewriting, are a really advanced feature that only Oracle has. In many warehousing or decision support applications, they are a must have feature that makes the difference between project success and failure.
Assuming you aren't in such a high performance setting, you can often simulate a materialized view by simply populating a transformation table using stored procedures. In such settings, I think either Firebird or PostgreSQL would work fine, cost less, and avoid icky proprietary licence restrictions.
Follow the first "Interbase" link in my post to read the explanation I'd written earlier. Some of the problems might've been fixed by now, but it boils down to this: PostgreSQL is widely used, fast, supports the same features, and has major commercial backing. Firebird's main strength is that is used to be Interbase and is a good thing for people with legacy applications built around that system. It's almost like a comparison of Python and COBOL - both are Turing complete, sure, but I'd hate to do new development on the latter unless I worked in a shop that depended on it.
Dewey, what part of this looks like authorities should be involved?
Slashdot reported it when Interbase was first announced to be going open source, and followed up on the actual releases afterward, so lots of people cared a few years ago. Interbase keeps getting mentioned by users in more general database discussions as well, so at least some Slashdot users still care, even users who are more interested in database features than in database names.
That's one difference. But query optimization is also a big deal. It's not obvious from simple queries, but MySQL takes a big performance hit if you do anything that involves relations between tables. That's why Slashdot went to indexing posts using a single field, instead of referencing the parent story every time. (It also has the effect of discouraging "first posts" since there's no longer a post #1. But Taco doesn't actually care about that!) I find it hard to take seriously any database that doesn't optimize queries.
I've used it in several projects, over the years. In my day job, we recently added Firebird to the list of databases that we support as warehouse targets for our application. Firebird's instant installation, small footprint, and portability (a few meg) are good reasons to do this. Another good reason is that it outperforms Oracle on the same hardware, as well as several other commercial databases.
We used to deploy Interbase as part of a product at a company I worked at years back. We would install, start the system (which had multi-gigabyte databases at times), and then not look at it again for YEARS. Two years could go by without tuning, transaction log clearing, or anything else, for that matter. It doesn't have transaction logs (doesn't need them), and sweeps itself clear of most detritus automatically.
Backups could effortlessly be done on the fly. Full two-phase commit support. And when it comes to complex transactions, it's one of the best databases out there because of its generational architecture (something it shares with PostgreSQL).
There are a few rough edges on it, like the lack of a standard GUI administration tool. Java support was slow to evolve. The lack of care given by Borland hurt the product for a time. The Firebird people seem to have done a lot of hard work, and deserve praise.
And for the record, Firefox or whatever the hell it is calling itself this week is one of the stupidest excuses for a software package I've seen to date. It's Mozilla minus most of the features that make Moz useful and extensible. It doesn't run any faster than Moz in resident mode. It performs no useful function I am aware of. The adulation it receives utterly escapes me; it seems to be a prime example of building software for the past. The engineering effort would have been far better spent on Moz itself.
Obviously you can generate duplicate rows any number of ways if you include non-unique column combinations in your SELECT.
In any rate, because SQL allows you to create a table *without* a primary key (which then means that result sets can have duplicate rows) then it is not relational. End of story.
No one is saying that SQL is double-plus ungood, just pointing out that it is not relational (just as saying that 2+2 != 5, and the sky is not made of fish), and don't attribute deficiencies of SQL to deficiencies of the relational model.
You can begin to understand how Date and Pascal et al at DBDebunk.com feel if you consider the following scenario (this thought exercise presupposes that perfect is possible):
Now that this long-winded description is over you can replace The Perfect Car with The Relational Model and "Perfect Car" Implementations with {Oracle, MySQL, etc.}. You can replace "New Perfect Car Models" (including "Without Significant Scientific Background") with {XML, OO-DBMS, 'Persistence Layers', etc.}.
No one is saying that you cannot use SQL products or XML, or that you cannot accomplish tasks in these tools, just that when used in the context of data management they are poorly solving what the Relational Model already solved.
Because IT practitioners are poorly educated and increasingly fad-driven they latch onto non-solutions (like XML, "Post-Relational", OO-DBMS, etc.) and put little or no pressure on DBMS vendors to get it right. Even worse, if someone does release a Truly Relational DBMS there are no guarantees that anyone will buy it due to the ignorance of the IT community.
Put simply: People don't know what they're missing, so they don't know to ask.
Thanks,
--
Matt
Firebird has a few minor claims to fame.
What about distributed transactions? AFAIK, no other open source relational database supports them (neither PostgreSQL, nor MAXDB, nor MySQL). I do quite a bit of distributed object programming, so I can't do without distributed transactions, and Firebird's work well.
What about server-side event notification? AFAIK PostgreSQL is the only other open source relational database that supports them. Switching from a polling architecture to event notification can yield huge performance benefits.
What about nested transactions? Firebird 1.5 supports savepoints, which are a basic rendition of nested transactions. AFAIK, MAXDB is the only other open source relational database with nested transaction support (though MAXDB's are full-fledged nested transactions, not just savepoints).
This isn't just some Firebird-propaganda-bullet-list. I find all these features indispensable.
Personally, as a DBA, I don't like mySql because of the numerous gotcha's it has unlike postgreSql. That speaks for itself... but hey, if you write bugfree code and trust that others do as well, then go ahead, use it. BTW> I'm a fan of postgreSQL, I wouldn't hesitate to recommend that if $$$ are a concern.
"Thanks to the remote control I have the attention span of a gerbil."