One of the strengths of the shelve module is allowing us to persist distinct items very simply. This imposes a design burden to identify the proper granularity, of the items. Too fine a granularity and we waste time assembling a container object from pieces scattered through the database. Too coarse a granularity, and we waste time fetching and storing items that aren't relevant.

Since a shelf requires a key, we must design appropriate keys for our objects. We must also manage the keys for our various objects. This means using additional attributes to store keys, and possibly creating additional collections of keys to act as indices for items on the shelf.

A key used to access an item in a shelve database is like a weakref; it's an indirect reference. This means that extra processing is required to track and access the items from the reference. For more information on weakref, see Chapter 3, Integrating Seamlessly - Basic Special Methods.

One choice for a key is to locate an attribute or combination of attributes that are proper primary keys and cannot be changed. Another choice is to generate surrogate keys that cannot be changed; this allows all other attributes to be changed. As shelve relies on pickle to represent the items on the shelf, we have a high-performance native representation of the Python objects. This reduces the complexity of designing classes that will be placed onto a shelf. Any Python object can be persisted.