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-tp30434629p30448940.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
