Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> comp.databases.theory -> Re: Is this bad design ?

Re: Is this bad design ?

From: Dawn M. Wolthuis <dwolt_at_tincat-group.com>
Date: Wed, 10 Mar 2004 08:43:53 -0600
Message-ID: <c2n9jh$5r5$1@news.netins.net>


"mAsterdam" <mAsterdam_at_vrijdag.org> wrote in message news:404f2635$0$575$e4fe514c_at_news.xs4all.nl...
> Dawn M. Wolthuis wrote:
>
> >>> Hand data with such relationships to any secretary in the 1950's
> >>> and they will know how to "model" it and store the data for
> >>> easy retrieval in their paper system.
> >>> Thank goodness they were not constrained by some desire
> >>> to "normalize" the data, eh?
>
> That databank would not qualify as large and shared.
> There would be no basis for such a desire.
> For small, shared databanks I prefer paper and pencil above
> computerized administrations. Of course this is only feasible if all the
> people sharing this administration have physical access to it, and
> all people that do can be trusted to care for the consistency and
> actuality of it.

I'm thinking in terms of the thick of a bell curve -- not those that are huge enough to end up in one tail or so small they are in the other.

> >>Dawn, what would you do if we extended the example and said that there
> >>is also another table called Father, and that every Child must also
> >>have a Father? The Child can't be modelled as an attribute of both
> >>tables, can it? And then another table called School, and another
> >>called Gang, ..., all with similar 1:M relationships. What then?
>
> > You are absolutely correct that if the requirements were different, then
I
> > would model it differently. I would also write all other aspects of the
> > applications involved differently. The requirements rule!
miles. --dawn
>
> They also change.

Yes, yes! We want to project well enough in advance to minimize major changes, but then ensure we have an implementation that can we can handily refactor as needed. In the relational model just having an attribute of an entity that switches to cardinality > 1 requires a refactoring to put that attribute in a separate table. The overall costs (including risks) of all refactorings required over the life of a system that is relevant.

--dawn Received on Wed Mar 10 2004 - 08:43:53 CST

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US