All the Perl that's Practical to Extract and Report

This problem calls for ... SQLite!

ziggy on 2003-02-02T21:34:58

Scot Hacker writes about some problems with Apple's iApps. Although they simplify working with digital media, they tend to bog down when large collections. Especially iPhoto. (I'm not sure if Scot is talking about the new iLife versions of iPhoto and iMovie, or the ones everyone has moaned about for months now.)

The problem is ineffiency dealing with large media collections. Scot describes the problems thusly:

To me, all of these database issues point to a similar need -- find a more efficient backing store for the iApps. The more I ask around, the more it seems that XML is the smoking gun on iLife performance drags - it's a great format for interoperability, but horribly inefficient and resource consumptive. Maybe, just maybe, it's time to reconsider using XML for the iApps. Maybe, just maybe, Apple should consider using some of the highly efficient open source database code out there -- MySQL would do nicely I'm sure.
Amen, brother! (But I think SQLite would be an easier choice....)

FireBird

gnat on 2003-02-03T16:52:14

When next I have an hour to mess around, I plan to look at FireBird, a the open sourced Borland InterBase. It has the interesting property of being embeddable--you can link against the table manipulation routines and suddenly you don't need a server. Kinda like the midpoint between MySQL and Berkeley DB.

Do you know of a table that compares and contrasts features of the various open source databases (subselects, transactions, embeddability, stored procedures, etc.)?

--Nat

Re:FireBird

ziggy on 2003-02-03T17:10:14

There's this one which compares MySQL, PGSQL, SABdb and FireBird. It lists ACID Compliance, stored procs, supported platforms, SQL compliance, subselects, and transactions, but not embeddability.

Re:FireBird

gnat on 2003-02-03T17:39:12

Very cool, thanks!

--Nat