On 7/6/06, Gussimulator <[EMAIL PROTECTED]> wrote:
Eduardo said:
> .... SQLite has no compression system for free.
Not for free?, I take it that its possible to implement a compression scheme
in the database system then. Which is what I care only - of course its
possible, but now I know its been done - Thats all I needed to know, since,
if every possible solution fails, I might have to implement this by myself,
low-level.
If this "compression-enabled package" uses its own compression algorithm/s,
then I'm ok with it not being free.. On the other hand, if they use a well
known open source algorithm, charging for this version is a little off... At
least from my point of view - of course it depends mainly on licenses and
points of view - I guess thats the case.
You get paid for your time. Someone who adapts a compression algorithm to
sqlite, even an open source one, should be paid for their time too.
Seems fair to me.
About normalization, even if I had a good work-around, that doesnt mean that
using a compression scheme wouldnt perform better on most cases. (Although I
cant tell speed-wise.
If you really desire to save space optimization by normalization will
help a great
deal. So long as you do it correctly. I worked on one database where they
normalized the state names in street addresses. They added a 4 byte integer
key to the address table to reference the state, a matching 4 byte integer
in the state table to identify the state and created a btree index to join the
two tables with. The keys in the two tables alone were 4 times the size of
a 2 byte state name. This design choice resulted in more disk space being used,
slower response time, and more difficult programming. You can over normalize.
--
SqliteImporter and SqliteReplicator: Command line utilities for Sqlite
http://www.reddawn.net/~jsprenkl/Sqlite
Cthulhu Bucks!
http://www.cthulhubucks.com
