Re: Normalization and DBMS
Date: Tue, 11 May 2004 20:10:10 -0500
Message-ID: <c7rti3$m51$1_at_news.netins.net>
"Leandro Guimarăes Faria Corsetti Dutra" <leandro_at_dutra.fastmail.fm> wrote
in message news:pan.2004.05.12.00.24.02.523801_at_dutra.fastmail.fm...
> Em Tue, 11 May 2004 17:07:47 -0500, Dawn M. Wolthuis escreveu:
>
> > such constructs are much more likely in a relational
> > database simply because there is no ability to have a "real" repeating
> > group for the grades (a little subtable within the table).
>
> Consider that subtables add lots of complexity with no added power.
I agree they add complexity of a sort and I agree there is no additional "power" but it seems to have a direct correlation to the flexibility of a system to withstand years of requirements changes. For example, if people used to have an e-mail address and now they have several, sometimes absolutely NOTHING has to change in the entire application other than to change the metadata for the field to describe it as permitting multiples. Of course, if a report prints on a fixed form with a box around an e-mail address and all, then that form and associated report would need changing. Also, if the developer's tools could not switch automatically from a fixed single value to a scrollable window of values then the data entry would need tweaking to scroll to multiple lines for entering that field.
It seems that cardinality really is a frequently changing requirement. However, when working with SQL-DBMS's, it seems that developers use clever methods to keep from building new tables when cardinality changes. So, a developer who can might just change cardinality from 1 to multiples, but a SQL-DBMS development team (note the change from 1 to many on the developer side -- not an accident) might be more inclined to add another column (you know I'm right!) stating that one e-mail address is the primary one and the other is a secondary one (thus, they are two different TYPES) and then suggesting we don't care about more than 2 for current purposes.
Do you agree with any part of that assessment and "guess" as to why it turns out to be advantageous to be able to bump up the cardinality of a field from 1 to many when needed? --dawn Received on Wed May 12 2004 - 03:10:10 CEST