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:
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.
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.
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.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
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