Re: Relation problem

Jan Hidders wrote:
>
> Kristian Damm Jensen wrote:
> > Jan Hidders wrote:
> > >
> > > Of course, but it also means that you will still have two tables Indiv.
> > > and Organ. that contain the class specific attributes and a foreign key
> > > to the Parties table. And the reverse of this foreign key is a "split
> > > foreign key".
> >
> > Correct. That is inherent in the nature of the data and can not be
> > avoided.
>
> Exactly my point. :-)
>
> > What can be avoided is some of the performance problems. Without the
> > supertype referential integrity from Adresses to Individuals and
> > Organizations can not be maintained using an index. With Parties it can.
> >
> > Ah, you say, but then you will just move the problem on to maintaing
> > referential integrity between Parties and Individuals/Organizations. But
> > as this will not be updated (!) the is reduced to deletion and
> > insertion, which I believe will happen much more infrequently.
>
> Very good point and you might be right about the number of updates. But
> it may depend upon the type of organizaton that you are dealing with.
> In some organizations clients come and go, in others they stick with
> the same supplier for years.

But even so, that will either be deletes and inserts or it will be updates of attributes and thus not affecting the referential integrity.

--
Kristian Damm Jensen              | Feed the hungry. Go to 
kristian-damm.jensen_at_capgemini.dk | http://www.thehungersite.com