Re: Normalization and DBMS

"Leandro Guimarães Faria Corsetti Dutra" <leandro_at_dutra.fastmail.fm> wrote in message news:pan.2004.05.12.03.22.43.667655_at_dutra.fastmail.fm...
> Em Tue, 11 May 2004 20:10:10 -0500, Dawn M. Wolthuis escreveu:
>
> > it seems to have a direct correlation to the flexibility of a
> > system to withstand years of requirements changes
>
> Quite to the contrary. With nested tables, the only way to
> ever reach the subtable is thru the supertable.

What problems are caused by this? I suspect there are some, but then there are tradeoffs. One thing that works well is the integrity -- when the parent goes away, so does the child table and there is no chance that a child will be born without a parent.

> On the other hand if you only have relations, the data will
> always be there...
>
>
> > 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.
>
> CREATE TABLE
> email
> (
> address,
> person_code
> )
>
>
> > However, when working with SQL-DBMS's, it seems that developers use
> > clever methods to keep from building new tables when cardinality
> > changes
>
> This is a tools issue, not a DBMS one. If the tools request
> codification changes, so be it. It is a low-level tool.
>
> For many good-quality screen painters and the like nothing
> will be required.
>
> You seem to be thinking about a 4GL. Aren't you one of the
> Pick guys?

Perhaps to the extent that I'm a guy ;-) but in case English is not your native language, I'll figure you were using the inclusive meaning of "guys" ;-) --dawn Received on Wed May 12 2004 - 05:40:10 CEST