Is their a practical limit to the size of a metakit db?
Short answer: YMMV. Long answer: see below.
Tom Krehbiel wrote:
Physical limit is that max file size on your file system.
I'm afraid that is not quite right. Physical limit is what fits into the address space as memory mapped files - on 32-bit address machines, it may be up to 2 Gb, but a practical limit is probably closer to 1 Gb. On 64-bit machine, the limits go up - but nothing will get rid of the need to analyze the specs and carefully design with the strengths and weaknesses of MK's column-wise storage in mind.
There are tricks to store unlimited amounts of data, by using MK *not* to store all data but only parts of it, and then have it *manage* data storage for the rest. A simplistic version of that would be: store really big items in separate files, and store the filename in MK. With such an approach, there are no real limits, evidently.
But above all else: the key trick is to take redundancy out of the data and reduce data set sizes. That can have effects of an order of magnitude on database size, sometimes even more - especially when recoding repetitive strings as separate indices into string tables.
I've been tempted a few times to write a wrapper view in MK which automates these tricks (both the external file storage and the "lookup table" ide), to hide them all behind a view layer. So far it hasn't happened, and no project has come up to let me justify working on this. Let me just finish by saying that I would not rule out MK for any amount of data - it obviously depends on requirements, usage scenario's, and acceptable development effort to make it happen.
-jcw
_____________________________________________ Metakit mailing list - [EMAIL PROTECTED] http://www.equi4.com/mailman/listinfo/metakit
