Re: Relation problem

I was afraid of that. Lots of queries will be based on this table to join people with their address. I haven't done any testing yet, but performance could be slow. I guess if I create a unique index on individuals and addressID, and another on organizations and addressID, it would help.

If you can think of another way feel free to let me know. I'll go with this one for know until true testing reveals the bottom line.

Thanks for your input.

Michel

Jan Hidders <hidders_at_REMOVE.THIS.win.tue.nl> wrote in message news:9474kn$41p$1_at_news.tue.nl...
> Michel wrote:
> > Jan Hidders <hidders_at_REMOVE.THIS.win.tue.nl> wrote in message
> > news:946blu$hkt$1_at_news.tue.nl...
> > > Michel wrote:
> > > > Designing this large database where we store adresses as their
> > > > own entity. i.e. an address exist by itself. We also have
> > > > individuals AND organizations that can have have more than 1
> > > > address. So far so good, created a link table were I wanted to
> > > > use the primary key as individualID and AddressID.
> > > >
> > > > This would be great, but it's got to be an individual OR an
> > > > organization, so I cant have referencial integrity enforced at
> > > > the database level.
> > >
> > > Why not simply split the table Addresses in OrganizationAddresses
> > > and IndividualAddresses? You can always define a view that takes
> > > the union of these two tables if you need it.
> >
> > Because I need to keep a single table of address with no duplicates.
> > We have regurlar updates for address validations, new addresses and
> > so on.
>
> Ah, Ok. Then there is probably no way you can solve this by choosing
> the right tables and you will have to resort to something like triggers
> to guard this constraint.
>
> --
> Jan Hidders
Received on Thu Jan 18 2001 - 17:30:34 CET