Re: Is this bad design ?

From: Dawn M. Wolthuis <dwolt_at_tincat-group.com>
Date: Wed, 10 Mar 2004 07:41:06 -0600
Message-ID: <c2n5tk$ubc$1_at_news.netins.net>


"Tony" <andrewst_at_onetel.net.uk> wrote in message news:c0e3f26e.0403100255.7a3f6f1d_at_posting.google.com... > "Dawn M. Wolthuis" <dwolt_at_tincat-group.com> wrote in message news:<c2m1ju$jrb$1_at_news.netins.net>...
> > "ben brugman" <ben_at_niethier.nl> wrote in message
> > news:404c9b34$0$281$4d4ebb8e_at_read.news.nl.uu.net...
> > > Mother table.
> > > fields:
> > > mother_id
> > > still_valid boolean
> > > etc_fields
> > >
> > > Child table
> > > fields:
> > > mother_id
> > > still_valid boolean
> > > more_fields
> > >
> > >
> > > The child.still_valid field always contains a true, because only
mothers
> > > withs are still_valid can have children, to enforce this; a relation
is
> > > defined on the fields mother_id and still_valid.
> > > (A child can not exist without its mother).
> > >
> > > Because a field in the child table always has the same value, I think
> > > there is something wrong. But if this field is taken away a mother
might
> > > become un_valid by another action.
> > >
> > > Is this bad design ?
> > > what is a alternative ?
> > >
> > > (As I understand constraints should be implemented in the RDBMS and
> > > not in the code).
> > >
> > > ben brugman
> >
> > This data could be modeled as:
> > Mother Table
> > mother_id
> > still_valid boolean
> > etc_fields
> > child* (* meaning can be multivalued)
> > more_fields
> >
> > If your database permits such modeling (no matter how it actually
implements
> > this), then the desired constraint is built in, including knowing
whether
> > the mother is still_valid and also getting deleted if the mother is
deleted.
> > 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?
> >
> > smiles. --dawn

>
> 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! smiles. --dawn Received on Wed Mar 10 2004 - 14:41:06 CET

Original text of this message