On 2006-05-04, Jonathan <dev101@magma.ca> wrote:
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.
Last year I hacked some ZCatalog replacement because I had a non-zope standalone ZODB application. It is only one single file containing a complete customizable indexer. Perhaps it is also useable here. http://files.banality.de/public/standaloneindexer.py Simon Pamies