Re: Multiplicity, Change and MV

From: Neo <neo55592_at_hotmail.com>
Date: 14 Apr 2006 13:13:18 -0700
Message-ID: <1145045598.619374.111990_at_e56g2000cwe.googlegroups.com>


> Bob: "Changing the schema requires schema changes." Well, duh.

The OP (a consultant) is smart enough to know that if the number of values for an attribute changes from exactly 1 initially to 0-to-many later, that this will require additional tables which then have undesirable side effects such as schema changes (additional tables and links), possible data migration (mostly between existing to new tables) and script/query/code/GUI updates. The OP is also smart enough to know that he could have started off with a schema allowing 0-to-many values for an attribute and then limiting to 1 value (via code), but such flexibility would introduce complexity that may never be utilized. And to allow such flexibility for every attribute of every table would be highly impractical. Even after realizing all this, he is asking: what initial schema will best allow me to avoid schema/query/code/GUI changes later. For obvious reasons (thus you "duh"), designing an initial schema/query/code/GUI that can handle data structures not known until some time in the future, seems contradictory. Designing an initial schema that can handle ANY data structure later is theoretically possible in RM but it is highly impractical to implement.

However, the experimental db accomplishes the above. It starts with a schema so general that the user never need specify a schema initally or update it later as it always allows (among other things) the ability for an "attribute" to have 0 to many "values" without NULLs. One side effect of this is that the burden of enforcing user constraints (except for referential intergrity which isn't a user constraint), such as an attribute can have only one value, shifts to the code interfacing to the db. Received on Fri Apr 14 2006 - 22:13:18 CEST

Original text of this message