[DB-SIG] DB scheme question

szncary szncary at gmail.com
Wed Dec 15 05:55:31 CET 2010

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

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


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
>>>contains up to thousands of atoms
>>>2. molecules - has some attributes (e.g. name, id, etc) and a group of
>>>(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
>>>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 at 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.

More information about the DB-SIG mailing list