Re: Is this bad design ?

A few observations....

1st, People have relations to other people with a 'type' of relation. (type is e.g., spouse and child -- the reverse is the parent/grandparent...etc). Then to show legitimacy, the father and the mother would both have a 'ownership' relation with a child. Guaranteed that a child needs a ma and pa - at least for the near foreseeable future . A 'valid' mother would be one with a 'valid' child and father (except for a few rare biblical references).

2nd, Teachers don't teach children (people). Teachers conduct a class and people attend the class. It is only happenstance that the person 'learns' or that the teacher 'teaches'. There are few occasions where people 'own' people (that went out of style some time ago). But there currently exists special data relationships between physicians and patients (people of type patient) and perhaps parole officers and people (parolees). At one time the teacher, being a mentor, allowed a closer teacher/student relationship. But alas, no longer.

3rd, the 1st is a bit difficult to do easily or in a straight forward manner with an RDMS. This then leads to why not a non RDMS answer if this is a newsgroup of 'theory'.

ben brugman wrote:

> Summerization of the mails (so far).
>
> First the 'problem' was a stripped down version of
> the 'real' problem. There are more tables, more fields and
> more relations. The stripping down was done to keep the
> example easier to read and still contain the 'problem'.
> This partly failed, because suggestions were given based
> on the simplisity of the example. But the child is a more
> complex object, having its own relation to other objects.
> (To keep to the terminologie, that could be grandchildren,
> fathers and teachers).
>
> (The "valid attribute" is an attribute which exists in the
> real world. Users using 'mothers' do know the meaning
> of a valid and non-valid mother).
>
> Suggestion A:
> Splitting the table in two were one table only holds the
> valid mothers and one table holds the non-valid mothers.
> This would mean a change in applications, a view would
> not work in my oppinion, because not all mutations
> are possible through a view. (For example the change
> from valid to non valid, but also other mutations).
> If there are more of these booleans. The splitting up
> process becomes complex. (If there are 3 'valid'
> booleans, we would end up with 8 tables.).
>
> Suggestion B:
> Including the children in the data of the mother.
> The children are more complex than represented in
> the example. (A child has relations with other objects
> as wel, call them teachers in this example).
> So this is not possible. (The example was to 'simple'
> to discern this).
>
> Suggestion C:
> Leaving out the "valid" attribute, because it is a real
> world attribute, the attribute has to be implemented.
> (One way or another).
>
> Suggestion D:
> "But, if database access is encapsulated in one class/package/module in
> your application, it should be possible to change the database schema
> without too much side effects? "
> If a design depends on encapsulation in one class/package/module is
> this not considered bad design ?
> This is/was one of the suggestions for implementation. The constraint
> check was also done in the application. We did run into problems with
> Oracle, because of the read consistency the rows which were not
> updated by the application could be changed by another transaction.
> In SQL-server the transaction had to run on the 'serializable level',
> a level not advised by several institutions and persons. Because of
> lack of experience with this level (at that time) we decided against this.
> (I still do not know if this was a right decision or not).
>
> Suggestion E:
> In the end we came with the following solution. We used a changenumber
> in the mother for all updates on the mother and her children and
> grandchildren.
> In our case this works, because the 'mother' is such an important
> object on our design.
> But an argument against this would be, what to do if we want to do a change
> on the children but this is based on a path were the mother is not the main
> object. For example a 'teacher' of the child construction. (Ok this is a
> bit fuzzy).
> As said in our implementation the mother is CENTRAL (important) that
> mutating the child involves 'locking with an changenumber' the mother worked
> very well. (And we do not need to lock the teacher of the child.)
> But if you want to mutate a lot with this type of constructions and you need
> more
> than one resource (mother, teacher etc) then there is a problem.
> So our actual implementation (different from the suggestion in the first
> mail)
> works, but I am not totally happy with it.
>
> Suggestion X:
> Human brain organisation. Sorry but I do not think this contributes to
> a solution of the problem.
> (Remark: The human memory is not designed to 'remember' acurately, but
> to survive. This means if alterations of 'memory' does aid in survival, the
> human brain has no problem with these alterations and so it sometimes
> does.).
>
> Conclusion :
> For the given problem I have not seen a design which can be implemented,
> (Oracle and SQL-server) which is not considered a bad design.
>
> Thanks to all who contributed to this thread.
>
> Ben Brugman.
>
> "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
> >
> >
> >
> >
> >
Received on Fri Mar 19 2004 - 01:48:47 CET