From the Berkeley DB docs:
Usually you find database records by means of the record's key.
However, the key that you use for your record will not always contain
the information required to provide you with rapid access to the data
that you want to retrieve. For example, suppose your database contains
records related to users. The key might be a string that is some unique
identifier for the person, such as a user ID. Each record's data,
however, would likely contain a complex object containing details about
people such as names, addresses, phone numbers, and so forth. While
your application may frequently want to query a person by user ID (that
is, by the information stored in the key), it may also on occasion want
to location people by, say, their name.
Rather than iterate through all of the records in your database,
examining each in turn for a given person's name, you create indexes
based on names and then just search that index for the name that you
want. You can do this using secondary databases. In DB, the database
that contains your data is called a primary database. A database that
provides an alternative set of keys to access that data is called a
secondary database. In a secondary database, the keys are your
alternative (or secondary) index, and the data corresponds to a primary
record's key.
This usage scenario can easily be implemented using ZCatalog (as Chris
mentioned) - check the ZopeBook for info.
Jonathan
_______________________________________________
Zope maillist - Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope-dev )
