Help for newbie

[Leuk]

Many thanks for your information and your advices.
regards
Jean-Louis
"Diez B. Roggisch" <deetsNOSPAM at web.de> a écrit dans le message de news: 
cnnfe4$qce$00$1 at news.t-online.com...
> Leuk wrote:
>
>> 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.
>
> -- 
> Regards,
>
> Diez B. Roggisch