erikcw a écrit : > Hi, > > I'm working on a web application where each user will be creating > several "projects" in there account, each with 1,000-50,000 objects. > Each object will consist of a unique name, an id, and some meta data. > > The number of objects will grow and shrink as the user works with > their project. > > I'm trying to decided whether to store the objects in the database > (each object gets it's own row) or to use some sort of data-structure > (maybe nested dictionaries or a custom class) and store the pickled > data-structure in a single row in the database (then unpickle the data > and query in memory).
Yuck. Fighting against the tool won't buy you much - except for interoperability and maintainance headeaches. Either use your relational database properly, or switch to an object db - like ZODB or Durus - if you're ok with the implications (no interoperability, no simple query langage, and possibly bad performances if your app does heavy data processing). > A few requirements: > -Fast/scalable (web app) > -able to query objects based on name and id. > -will play nicely with versioning (undo/redo) Versionning is a somewhat othogonal problem. > Any input on the best way to go? My very humble opinion - based on several years of working experience with both the Zodb and many RDBMS - is quite clear : use a RDBMS and use it properly. -- http://mail.python.org/mailman/listinfo/python-list
