07-09-03, 09:02
|
|
Registered User
|
|
Join Date: Sep 2002
Location: Montreal, Canada
Posts: 219
|
|
|
Re: firebird
Quote:
Originally posted by unordained
In case you haven't made a choice yet, I'll post my opinion.
I'm a firebird user -- I'm the DBA (when needed, which is not often) and the tech-lead for the team. I'll vouch for firebird in the places I've used it -- we access it from a fat client (c++/win32) at my main job, and I've used it with php several times for websites (in fact, helped report problems to the php team when ibase_* functions were having issues.)
It's reliable. It's stable. It's fast. It's got the features you will likely need. And it's generally "correct" in the logical sense: transactions aren't just a random feature. They're part of relational theory, when it comes to a multi-user database system. If it's interactive, if it's mission-critical data, if it's a multi-user system ... go with something designed for those. Postgresql, firebird, SapDB, ... find whatever you like. But please don't use mysql. (all three mentioned are free.)
(and yes, a web-app SHOULD use transactions to make sure semi-simultaneous page hits don't run into problems because of updates occurring somewhere in the database, whether it's from the web, or from an internal database feeding stuff to it. and a db like firebird where transactions are part of the very essence of the database system, not an add-on ... means that if your power fails, or something else goes wrong, your db will still be in a perfectly valid state, ready to go again. it's a bit like the difference between fat32 drives and ext3 or reiserfs -- don't you want your data to be safe?)
|
Well, MySQL handles transaction now with the InnoDb handler (which comes standard now). So there's not problem on that side and for read-only stuff, nothing is as fast as MyISAM tables (expect Oracle). The only thing missing now are views... But it's coming soon...
|
|