Actually, this was precisely the situation in which multiple LC arrays, being used as "tables", where the array key was the primary key of the "table", and joining these "tables" was far faster to do using LC arrays than any in-memory SQL database. Admittedly these were only 2-way and 3-way joins, so _maybe_ if they were 7-way joins I might not have seen the same performance difference.
If you need a RDBMS (and integrity checks, triggers, etc), then you probably do need it -- there's no point in re-inventing the wheel. But if you need to just store a list of blobs, then an array with pointers to blobs on the filesystem might still be much faster (and much simpler). I'm not opposed to RDBMS per se. In my time, I've used Oracle, Firebird, Frontbase, Postgresql, Openbase, HSQL, Valentina and Sqlite, and I still use some of those if the situation needs it. Bernard On Wed, Dec 21, 2011 at 2:25 AM, Pete <[email protected]> wrote: > But as soon as you get into multiple datasets with links between them or > multiple ways to access one dataset or multiple users accessing the same > data, there's a strong justification to use a database unless the > performance/memory issues are so bad that you can't deal with them (which I > find difficult to believe). _______________________________________________ use-livecode mailing list [email protected] Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
