Re: Is this bad design ?

"Dawn M. Wolthuis" <dwolt_at_tincat-group.com> wrote in message news:<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

So, MV is only suitable for fairly simple cases where the "Child" is nothing more than an attribute of the "Mother"? If the Child is more significant than that you would do what - something more like a relational foreign key? Received on Thu Mar 11 2004 - 01:12:09 CET