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.
The only reason anyone even knows about them anyway is because of the former Mozilla Firebird. :O
Just kind of curious if anyone would care at all if there hadn't been the big stink with the name conflicts.
I mean, has anyone used this database? Is it really of any note that v1.5 is out?
-- taking over the world, we are.
I'm so glad this version of FireBird renders CSS properly... no wait...
/^[A-Z0-9._%+-]+@[A-Z0-9.-]+\.[A-Z]{2,4}$/i
no it's a database!
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
Firebird works really good for Web sites.
Much better than Internet Explorer.
Due to trademark infringement potential and other potential confusion, Firebird Database Engine has just changed its name to
F------d Database Engine
More news to follow.
P.S. For any lawyers, etc. reading this, the above is an example of "parody", not subject to the definition of "slander" or "libel".
Rhymes that keep their secrets will unfold behind the clouds.There upon the rainbow is the answer to a neverending story
Specifically what did they do wrong in your eyes? When Mozilla takes an existing project's name are they just supposed to accept it and change their name? That doesn't sound very fair.
Finkployd
I work as a data-mining professional and aside from creating statistical models on flat-files, I manage the process of transforming and joining relational databases into a a flat file for model building.
Currently we use Oracle for this work, but in the past we tried switching to MySQL but found that it lacked some of the key features such as materialized views, nested sub-queries and a variety of Oracle SQL functions that we find useful. MySQL seemed to be geared towards maintaining a real-time database to support customer interaction, rather than as an environment for assembling static data sources.
Could Firebird be a viable open-source alternative, or are there others?
So, I typed in slashdot.org but somehow I ended up on freshmeat.net. wtf?
Firebird is SQL, not relational.
Yip yip yip! Ow! I sprained by brain!
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.
Why are you people bashing so hard about the naming issue? You know what? I don't care!
I know Firebird DB since it's earlier days and I was a Interbase user before that. And I loved it. Why? Because the kind of job I did that time required a simple, efective, maintence-free database and Firebird is exactly that. You can just install it and forget it. The whole database is just one file (at least was) so a simple tar or zip will backup your stuff.
Yeah, yeah, I know there is MySQL, PostgreSQL, etc but as I said, I'm not on this kind of job anymore and even if I was, while firebird does what I want (and well) why should I care about other RDBMS?
Scientia est Potentia
to serve up pages, one to view them... and one Firebird to rule them all?
Karma: Contrapositive
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).
Mysql easy?? I couldn't even begin to get it to install so I had to revert old school and use a sheets of paper and a filing cabinet for my database.
I don't think there's ever going to be a truly light and fast database server that pleases everybody.
Why?
Because to please everyone, you have to...please every one. Which means to offer the features they need. And even if you're an ace programmer, I don't think it's all that easy to de-couple the code to the point that you can just flip a few compiler flags and add or remove features at will.
For instance, all you need is replication. What if someone else doesn't give flying rip about replication, but needs 100% Ansi SQL 99 compliance (something that very few database servers seem to have, oddly). In the stable releases of MySQL, subqueries aren't available. Subqueries! Don't tell me that you can always do the query some other way; I want my subqueries. So I opted for the heavier Postgres engine. When MySQL's stable version offers subqueries, I may switch to it, but at this point I'm fairly familiar with Postgres and don't necessarily want to risk having to rewrite thousands of lines of query code ("Standard" Query Language?!? *What* standard?)
Because there's no one group to please, I don't think anyone's ever going to "fill this niche" because there are a hundred other niches that need filling -- after all, for some people, internationalization and ISO Latin capabilities are crucial; for others, it's roughage.
Database development takes a while -- or at least, it takes a while to do well. There are a ton of MP3 players out there that actually work, but very few database servers that do. It requires a lot of mathematical, computational, and algorithmic knowledge, as well as being kept up to date on the latest in sorting methodolgies, matrices calculations and who knows what else (I sure don't!). So it's only really "profitable" to have one database project that offers all of the features people ask for, rather then 5 that cater to different preferences. Even "bulky" database servers like Postgres seem to run fine on what are today considered "obsolete" computers, so "fast" and "small" are not really the number one criteria anymore.
Karma: Chevy Kavalierma.
I think that this reduces uptake of the database, becuase of the barriers to just taking a casual peek of their features. The whole documentation is just locked away with the keys.
Perhaps this is becuase they want more people to have paid support? A PDF manual is all well and good, but at least give us a bone to chew on with a feature list, reasons why people should use the database and so forth.
Newsfollow.com
While Postgres is the better database, installing Firebird/Interbase is a much easier task for the average user. That makes it a terrific little cross-platform client-caching database, such as letting the spreadsheet users slice at the data with an ODBC driver without killing the primary database server. For the same reasons, it's a handy tool for writing small standalone database apps without locking in to a Win32 codebase (e.g. MS Access.) I'd say it even has potential to serve the same kind of markets that the "light" servers like Sybase SQL Anywhere serve.
I do not fail; I succeed at finding out what does not work.
Ohhh. and I need a dump truck that's fast and small, but can carry 28 metric tonnes of stone at the same time. And it needs a built in hot tub. And a satellite dish.
Comon, every piece of software is a compromise. If you need a lot of features, then it isn't gonna be small. If you need it small and fast it's gonna be missing some features.
Fast, featureful, small. Pick two.
--- It is not the things we do which we regret the most, but the things which we don't do.
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
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."