dbTalk Databases Forums  

Multiple records in secondary db per record in primary db?

comp.databases.berkeley-db comp.databases.berkeley-db


Discuss Multiple records in secondary db per record in primary db? in the comp.databases.berkeley-db forum.



Reply
 
Thread Tools Display Modes
  #1  
Old   
Pelle
 
Posts: n/a

Default Multiple records in secondary db per record in primary db? - 12-11-2005 , 09:04 AM






Hi,
I am writing an application that is going to use Berkley DB to store
lyrics, using the C++ API. I need to be able to search for lyrics by
author.

So far so good, secondary databases are there to do just that, but some
of the songs have more than one author. How am I going to do this? The
key extractor callbacks does only seem to allow creation of one record
per record.

Are there any ways to do this, or do I need to do this manually (using
only primary databases)?

Thanks,
/Per Eckerdal


Reply With Quote
  #2  
Old   
Michael Cahill
 
Posts: n/a

Default Re: Multiple records in secondary db per record in primary db? - 12-11-2005 , 06:06 PM






Hi Per,

Quote:
So far so good, secondary databases are there to do just that, but some
of the songs have more than one author. How am I going to do this? The
key extractor callbacks does only seem to allow creation of one record
per record.

Are there any ways to do this, or do I need to do this manually (using
only primary databases)?
Berkeley DB's associate call doesn't directly support what you need.

There is a limited way to do this that might work here. If you can put
an upper bound on the number of authors (if, say, no song ever has more
than five authors), then you can open that many handles on the
secondary (author) database, and associate handle with the primary.
You'll need a separate callback to extract the first author, the second
author, and so on.

The callbacks can return DB_DONOTINDEX if a song doesn't have that many
authors, so the secondary won't be bloated. And all of the authors end
up in the same database, so you can search for an author without having
to know whether s/he is the first or second author of a song.

The big limitation, of course, is fixing the maximum number of
secondary keys, and the clunky setup. Sleepycat have discussed
implementing 1:N secondary indices, but as far as I know it isn't on
anyone's schedule. If this feature is of general interest, please let
us know.

Michael.



Reply With Quote
  #3  
Old   
Pelle
 
Posts: n/a

Default Re: Multiple records in secondary db per record in primary db? - 12-12-2005 , 03:11 PM



Thanks for the reply.

This application will be pretty small, with pretty small databases
(never more than 1000 songs), performance isn't that critical, and DB
is only to be used internally by one isolated part of the program (an
XML format is used as interface to "the world"). Actually, even if the
application would crash together with the database, that wouldn't be
unforgivable either.

Because of this, I think I will go for not using secondary databases on
the keys that require 1:N indices, and do the work "manually", by
creating wrapper functions around the put and del functions. I can
understand that this might be inpossible for larger applications, but
it isn't really hard to work around in this case.

Generally, I think this would be a very useful feature, though. I can
think of many more cases than this where this would be useful. I might
be forced to use some other database software sometime in the future
for this reason. (But this is still just one 16 year old student from
Sweden's opinion. I am actually a little bit overwhelmed: As I
understand it, someone from Sleepycat actually read and answered my
question within 24 hours.. That's a good first impression)
/Per Eckerdal


Reply With Quote
Reply




Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off



Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.