> but I still have my head too wrapped around the relational model. I am trying to build a simple application just to learn the basics of Durus, but everything seems so deceptively simple. I keep wondering if there is something I'm missing. Welcome to the list, and the club ("seems so deceptively simple"). I felt that way after first looking at ZODB and Durus years ago as I'd been working with software based on RBDMS persistence for more than a dozen years at the time. I remember feeling dis-join-ted (pardon the sql pun) and uncomfortable. Rest assured this will pass, the feeling is only temporary. My advice would be to focus on modelling your application objects as classes and force yourself to keep thinking in simple terms. Try to avoid thinking about indexing for now; in time you may find as I did that you end up needing far fewer indexes than you might currently imagine, and in these early days of exploring what can be done with Durus for Python object persistence, dwelling on indexing will only serve to keep you thinking in sql-speak. Persistent objects and containers will get you a long way. people = {} class Person: def __init__(self, id): self.id = id self.subscriptions = [] class Subscription: # ... mw = Person() people[mw.id] = mw mw.subscriptions.append(Subscription('Some Magazine')) # query mw.subscriptions # returns all the person's subscriptions I bet your perception that it "seems simple" is thanks to your own realization that you can do an awful lot with basic Python objects like lists and dictionaries (I've not used the persistent versions above just for clarity). We've done above the equivalent of defining and creating two SQL tables, a foreign key relationship, insert the Person row, the related Subscription row, and queried the subscription table for rows belonging to the 'mw' Person. I would recommend reviewing the Keep and User code in QP itself and then perhaps look at a more complete implementation of User management in the Dulcinea package David referred to.