Re: Multiplicity, Change and MV

The biggest drawback is you are replacing a graph with a tree. In doing so you will always lose information and always lose consistency. For example, if you update french
 to "le français" you will have to know to update it in 3 locations. Your application will have to insure that transactional integrity and ACID is enforced. If you just place it in some sort of look up, then you only have to change it once. This is what good normalization buys you.

1:1 relationships, in schemas implemented in the current table based paradigm, should be in one table, as it implies a key and attribute.

1:M can create a tree.

But being able to think in M:M is the most useful as trees are very rare in real life.

Based on years of practicle experience, in order to keep changes minimal you must first understand the business processes very well. This will lead you to the business objects and the data produced. When you understand the data then you can create a schema.

Much of what I have done the past 5 years has been understanding my employers business processes and pointing out and resolving where the information was incomplete information and inconsistencies (2 departments can often have radically different views of the world!). I sometimes half-jokingly say that helping management understand their business processes has done more good than all the code I have delivered.

In other words, poor schema design comes from a poor understanding of the requirements. Which can then require major query rewrites. When I do find I need to rewrite a query I often use views to abstract out the changes.

HTH,
P. Received on Mon Apr 10 2006 - 23:10:28 CEST