Re: multiple table design problem

> b) why do you want to store adress data in an independent relation? Is
> a adress something with it's own identity? IMHO, design the objects as
> you look at them in real life: a hotel has adress attributes, a guest
> has adress attributes and they (the adresses) are not related to each
> other. They are just dump attributes. So I would prefer version 3.

hi Marc,

I think you've got a point here...
I also wanted to store the attributes with the hotel, guest, ...

I want to do this because the idea is that a hotel, guest or personnel can have more than one contact information... so it can't be put into the same table. I think it's not a good solution to create hotel_contact, guest_contact subtables for every type...

Another issue is that contacts are very important in this database for export to other programs and I think it's convient to have it all in one contact table where I just run a query like "SELECT * FROM contact WHERE contact_type = 2".

What do you say about this approach?

Best Regards,

   Georg. Received on Tue Feb 12 2002 - 19:18:34 CET