Leuk said:
I would like to use ZODB, but I'm a newbie in Python, so I do not know if
it be more easy for me to use PostgreSQL.
Some one can tell me what database will be better to use? What are de
differencies between this two databases?
To use zodb after you installed it is a piece of cake. It goes along these
lines (they are from an actual project, so they aren't spiced up as proper
example code
db = ZODB.DB(ZODB.FileStorage.FileStorage(database))
conn = db.open()
dbroot = conn.root()
As dbroot is a dictionary-like object, you can start inserting arbitrary
objects there, as long as they extend from the class Persistent. There are
tutorials/examples out there, that will show you the neccessary stuff.
On the pro side, zodb is an object database - you can more or less stuff
everything in there, and retrieve it as objects again - no object
relational mapping and so on. Even complex object graphs can be stored, n:m
relations are simply modelled by python's list and dict types - actually,
there are some zodb-classes that you need to use for practical reasons, but
the interface is the well-known one you love form your common python
container objects
You also don't need any server infrastructure.
The cons are to my POV:
- the more explicit data model of an rdbms like postgres allows for easier
migration. If your zodb storage contains objects of type foo, which you
then alter, it can happen that restored objects are not what you expect
them to be - they might miss data. While data migration is a matter in
rdbms too, its somewhat easier due to the simpler structure of the data.
- no builtin querying, let alone indexing. I've actually written my own
object query language (which is fun for starters, but gets tedious). So if
you are going to create much reports, zodb might not suit you so well. Of
course you can write all sorts of extensions - ZCatalog is a powerful
example - but in the end, you'll write a rdbms-like thingy on top of zodb.
then a rdbms might be the betteor choice in the first place. And there is
of course no shell-like interface to your db, as these are provided for the
rdbms out there.
- collisions after concurrent modifications can be a nasty thing - an the
docs are not to clear about what to do. It took me quite some time to solve
some issues with that.
- the advantage of no need for infrastructure can be a disadvantage of
course - as you have no model of acces rights on your data, you have to
somehow insure that yourself. Having said that, one has to keep in mind
that most database driven apps also only have one user for the connection.
I once tried to utilize the elaborated oracle user rights management, and
failed miserably - its a complicated endeavour.
While the cons seem to outweight the pros in sheer number, my personal exp.
is that at least for prototyping and from a pure programmers POV, ZODB
wins. Maybe if the project is mature enough, you can go and create
object2relational mappings - but through developement, things are nicer in
zodb.
