If I understand your original question correctly you are looking for a versioning system for a file or files which do not change very much between versions.
I would recommend subversion. It is very economical in its storage and suits your stated purpose. However, your later response (below) indicates you are building an application and are looking for an OOP design. Translating an OOP design into a database schema is often tricky. In your case, matter could be treated hierarchically like this ... matter --1:n-->> molecule --1:n-->> atom - where matter is made up of many molecules and molecules are made up of many atoms. Versioning this wouldn't be too difficult in a separate history table. However, there is likely to be atomic link information. The type of atomic bonds and energy involved to maintain a particular molecular state. Hence I might be tempted to use a molecule record to carry that information. Many-to-many relationships can be implemented with so-called dummy records each of which represent a relationship. These could represent particular atomic bonds in the context of a single molecule. The bottom line for your design will depend upon the user interface. You haven't given enough detail to comment realistically. Additionally, this is probably not the right forum for your question. I believe this group is more focused on APIs than schema design. Google might help S John Q. Public wrote: > > Hi Dieter, > > I don't think I fully understand your suggestion. > From an OOP point of view, my application consists of 4 objects: > 1. atoms > 2. molecules - contain atoms > 3. matters - contain molecules > 4. versions - contain all the above > The scheme suggested has 4 tables to hold the objects and 4 more tables to > represent the connections by pairing foreign keys (e.g. atoms in > molecules, molecules in matters and the three of the above in versions). > Since I lake the experience in db programming, I would appreciate if you > can point my implementation mistakes so I could learn from them. > > regarding the redundancy, each version contains few thousands of atoms, > molecules and matters and the differences between versions is up to few > tens. Isn't it a waste to hold all this relations in a table > (atoms/molecules/matters to version). On the other hand, is it possible > that my suggested relation might cause inefficient SELECT statements when > searching for a version parameters? > > J. > > > Dieter Maurer wrote: >> >> John Q. Public wrote at 2010-12-11 10:18 -0800: >>>Before I can ask my question, I have to present the data I work with. >>>My goal is to create a (very) simple version control for a unique type of >>>(text) file. >>>The file has three parts: >>>1. atoms - set of attributes (e.g. name, id, etc). Each version of the file >>>contains up to thousands of atoms >>>2. molecules - has some attributes (e.g. name, id, etc) and a group of atoms >>>(list of atoms ids). Each molecule can contain zero to hundreds of atoms. >>>3. matter - a group of molecules (a matter to molecule is what molecule is >>>to atom - and no, it's not homework of some kind....) >>> ... >>>Each file version is only slightly different from the previous version >>>(changes in only few atoms, molecules and\or matter). >> >> I am an object enthusiaste and therefore tend to regard the >> world in object oriented terms. >> >> Therefore, I would model your version problem as a set of objects >> and then use an object relational mapper (e.g. "SQLAlchemy") to >> map this to the relational model. >> >> If there is no need to avoid redundancy across versions, >> the version model could be extremely simple: each version >> contains copies of its components. >> >> >> >> -- >> Dieter >> _______________________________________________ >> DB-SIG maillist - DB-SIG@python.org >> http://mail.python.org/mailman/listinfo/db-sig >> >> > > -- View this message in context: http://old.nabble.com/DB-scheme-question-tp30434629p30461105.html Sent from the Python - db-sig mailing list archive at Nabble.com. _______________________________________________ DB-SIG maillist - DB-SIG@python.org http://mail.python.org/mailman/listinfo/db-sig
