I'm going to look into this too but what I had in mind was some kind
of maintenance you were running at one of your clients or something
like that.


On Tue, Jul 21, 2009 at 7:42 AM, Alexander Burger<a...@software-lab.de> wrot=
> Hi Henrik,
>> I vaguely remember a discussion approaches to cleaning or optimizing
>> databases, I searched the mailing list however without success.
> I'm not sure. There was a response (to some questions by Tomas) in
> =A0 http://www.mail-archive.com/picolisp@software-lab.de/msg00073.html
>> > What are the rules/heuristics for splitting entities and relations
>> > into database files?
>> As you perhaps know, you can specify database files and sizes with the
>> 'dbs' function, which results in the initialization of the global
>> variable '*Dbs'. You can see examples in "doc/family.l" and "app/er.l".
>> As a minimum, I would recommend to separate objects and B-trees. Usually
>> I experiment with the data model at the beginning of a project, and look
>> at typical entity objects with 'size'. Then I specify a file for each
>> size.
>> The B-tree block sizes seem to be not very critical. A block is filled
>> up dynamically anyway. It makes sense to put related indexes into the
>> same file, or use a separate file for each index if the database is
>> going to be big. I would put all small indexes together into a few
>> files, and put each big index into its own file.
>> At least for not too big databases, performance does not seem to depend
>> very much on the block size. A value of 3 (block size 512 bytes) or 4
>> (1024) seems a good compromise. Only for very large databases (more than
>> 10 million objects) I found that using very large blocks (6, resulting
>> in 4096 bytes) improves performance.
> Was this what you had in mind?
> Cheers,
> - Alex
> --
> UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=3dunsubscribe
UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe

Reply via email to