Re: Is this bad design ?

"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?

Well, uh, that's sort of why we don't use paper systems any more. That was as good as it could get. Even they had indexing systems which, in some cases, resembled aspects of relations. Unless in order to find a piece of paper X you'd suggest they just go hierarchically through every folder...

• erk