Hi,
Im not sute on how exactly to use the berkley db.

I want to make a document database.
But I dont know how to do this by using berkleys db.
Ive so far figured out that: (please correct med if im wrong)
I will be using the btree aceess method.
Key should be id. I will only need to search on the Id number.
The value will be some sort of encoded values. eg.:
Title
author
isbn

My problem is.. how should i make this?
My initial idea would be something like:
Fixed 30 chars for name, 50 chars for Title etc.

But the database will be quite large, so will it be better to do
something like:
first 2 bytes telling how long name will be(for example 15). at 17'th
byte there is 2 bytes telling how long title will be etc etc.
Is this a good way of doing it? or do berkkley db only have fixed
length on the btree access method?

/Lalleh

fartzzz (AT) bonbon (DOT) net (lalleh) wrote in message news:<b312d752.0408090754.65cb4347 (AT) posting (DOT) google.com>...

If the key is a sequentially incrementing ID number, you may
want to use the Recno access method.

Alternatively, if you are creating your own record numbers,
you should review FAQ #6 from the "Access Method FAQ":

I'm using integers as keys for a Btree database, and even though
the key/data pairs are entered in sorted order, the page-fill
factor is low.

This is usually the result of using integer keys on
little-endian architectures such as the x86. Berkeley DB sorts
keys as byte strings, and little-endian integers don't sort well
when viewed as byte strings. For example, take the numbers 254
through 257. Their byte patterns on a little-endian system are:

254 fe 0 0 0
255 ff 0 0 0
256 0 1 0 0
257 1 1 0 0

If you treat them as strings, then they sort badly:

256
257
254
255

On a big-endian system, their byte patterns are:

254 0 0 0 fe
255 0 0 0 ff
256 0 0 1 1
257 0 0 1 1


and so, if you treat them as strings they sort nicely. Which
means, if you use steadily increasing integers as keys on a
big-endian system Berkeley DB behaves well and you get compact
trees, but on a little-endian system Berkeley DB produces much
less compact trees. To avoid this problem, you may want to
convert the keys to flat text or big-endian representations, or
provide your own Btree comparison function.

I can't say if it's a good idea or not -- run-length encoding
can save a lot of space, in some data sets.

Berkeley DB does support variable length records for the Btree
access method.

Regards,
--keith

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Keith Bostic bostic (AT) sleepycat (DOT) com
Sleepycat Software Inc. keithbosticim (ymsgid)
118 Tower Rd. +1-781-259-3139
Lincoln, MA 01773 http://www.sleepycat.com