Elbonian database technology, part II

cp kindly commented on my last post regarding Open Source databases, and suggested two others I should go look at, SapDB/MaxDB and Firebird. I looked at MaxDB, and it is a re-branded and enhanced version of SAP DB, SAP AG's open source database. It has been taken over by MySQL AG, and it appears that it will eventually be merged into MySQL. It therefore doesn't look like a particularly good choice, as it might not be around in the future.

I then went and looked at Firebird. This started out as Borland's InterBase product, which they released as open source in 2000, then changed their minds and tried to close it back up. The result was a fork - the original Borland code was taken and rewritten in C++ (no, I have no idea why) by the Firebird community (including the original Interbase author) that developed around the original Borland code release. It's an interesting story that anyone who is thinking about open sourcing a large piece of software (*cough*) should be aware of. The documentation is a bit thin - the Firebird website relies heavily on the Borland docs, but it seems to be a mature product, so I'm going to give it a whizz.

Categories : Tech, Work

Re: Elbonian database technology, part II

In your original post complaining about lack of proper cursors, you also say you want to keep the barrier of entry low. I think using a "rare" database would count against this.

Maybe it would be better to use the mysql_store_result=false, but just on the large queries (assuming there's only a few selects likely to run through thousands of rows or more).

PS I dunno if Perl would be considered a lower barrier to entry than Java or not. If it's mostly for sys-admin types, I'd guess so, but maybe not in other cases. At least with Java, the JDBC drivers do not cache all the selected rows, on any database.

Re: Elbonian database technology, part II

Hi Chris, the 'rare' database point is a very good one, and one that is tipping me towards MySQL, despite its deficiencies. On the other hand Firefox is on SourceForge and does appear to be a bit more 'grown up' than MySQL - choices, choices!

If I go for MySQL I'll probably patch the DBD::mysql driver so that you can specify the mysql_store_result behaviour on a per-database handle level, with the ability to override it on a per-query level when required - in fact I can't understand why this wasn't done in the first place, the DBI module makes extensive use of this.

As to the perl issue, I've already written the analysis part of the app in perl using the perl Storable mechanism for persistence, so all I'm really looking to do is to migrate the existing data into something that doesn't require you to write perl to get access to the data. Putting it in a SQL database seemed to be the obvious choice.

Re: Elbonian database technology, part II

I've taken a good look at Firefox, and it basically looks like a bag of disconnected bits - no README, a load of prerequisites needed to get it to build etc etc, so it looks like I'm going to stick with MySQL and fix the DBI driver so that it allows a query's mysql_store_result flag to be inherited from the parent database handle.