I'm attempting to come forth with a great design for that storage of the data model. The word what is python, however i guess this really is fairly agnostic.

Right now I picture three possible methods:

Object database

The datamodel is really a network of objects. After I create them, I specify them as descendant from the persistence object. Example:

class Tyres(PersistentObject):
    def __init__(self,brand):
        self._brand = brand

class Car(PersistentObject):
    def __init__(self,model):
        self._model = model
        self._tyres = None
    def addTyres(self,tyres):
        self._tyres = tyres
    def model(self):
        return model

The customer code is unaware of the persistence, it manipulates the item because it is at memory, and also the persistence object takes proper care of everything with no client code knowing. Retrieval can be achieved using a keyed research of the database object. This is actually the approach that Zope Object Database (among many more) use. Advantages are lazy retrieval and changes are operated only within the objects which are transformed, without locating those that are untouched.

Shelving objects

The information model given above is symbolized in memory, but a database will be accustomed to push or pull data as monolitic organizations. for instance:

 car = Car("BMW")
 tyres = Tyres("Bridgestone")
 car.setTyres(tyres)
 db.store(car)

This is exactly what a pickle-based solution does. It's, in certain sense, like the previous solution, using the only difference that you simply keep object like a single bundle and retrieve it again like a single bundle.

The Facade

Just one database class with convenience techniques. Client code never handles objects, only ids. Example

class Database:
     def __init__(self):
         # setup connection

     def createCar(self, model):
         # creates the car, returns a numeric key car_id

     def createTyresForCar(self, car_id, brand):
         # creates the tyres for car_id, returns a numeric id tyres_id

     def getCarModel(self, car_id):
         # returns the car model from the car identifier
     def getTyresBrand(self, car_id, tyre_id):
         # returns the tyre brand for tyres_id in car_id.
         # if tyres_id is not in car_id, raises an error.
         # apparently redundant but it's not guaranteed that
         # tyres_id identifies uniquely the tyres in the database.

This option would be rather questionable. The database class may have a large amount of duties, however i kind possess the feeling that this is actually the philosophy utilized in Cleaning soap: you do not get to control an item directly, you perform inquires for object qualities to some remote server. In lack of SQL, this could apt to be the interface to some relational database: db.createTable(), db.insert(), db.select(). SQL simplifies this to acquire a quite simple db interface, db.query(sql_string) in the cost of the language (SQL) parsing and execution. You'll still reach work on the subparts from the data model you are looking at, without touching others.

I must request your opinion concerning the three designs, and particularly the 3rd. Just when was it a great design, when ?

The inverted logic

This really is something I have seen on MediaWiki code. Rather than getting something similar to

 db.store(obj)

they've

 obj.storeOn(db)

Edit : The example datamodel I show is a little simple. My real goal is to produce a graph based datamodel (if anybody wish to participate towards the project I'd be honored). What worries me from the third solution strongly encapsulate the written datamodel (instead of the in-memory one) and masks the after sales, however it risk to inflate as there's just one central class with the techniques uncovered. I have to be truthful, I do not such as the third situation, however i considered it just as one solution, and so i desired to use it the dish from the question. There might be good inside it.

Edit 2 : added the inverted logic entry