designing a document database as value - 08-09-2004 , 10:54 AM
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.:
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
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?
Re: designing a document database as value - 08-09-2004 , 08:43 PM
fartzzz (AT) bonbon (DOT) net (lalleh) wrote in message news:<b312d752.0408090754.65cb4347 (AT) posting (DOT) google.com>...
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:
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.
can save a lot of space, in some data sets.
Berkeley DB does support variable length records for the Btree
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