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.

Zope maillist  -
**   No cross posts or HTML encoding!  **
(Related lists - )

Reply via email to