John Browne wrote:
Ok, I'm designing a new database for work, and I have run across a situation where a "conditional relationship" makes sense. Here is a *simplified* example of what I'm talking about:
tb_address_data_us address_id addr1 addr2 city state zip_code
tb_address_data_ca address_id addr1 addr2 city province postal_code
tb_offices office_id manager_name date_opened
tb_addresses_2_offices office_id country_id address_data_id
As you can see, the "link" table is tb_addresses_2_offices. This model makes it easy to add additional address templates in the future, just by adding a single data table for the new country. But, it means the address_data_id can point to an id in any of the address data tables. I've done some reading, and some say it's fairly common to see this type of model. Others say it breaks database normalization rules.
My question is, how often do you guys see this in "real-world" scenarios? Obviously, it makes things like foreign key constraints difficult to use..
Thoughts?
Okay, these address/office entries are for a company/customer/user/etc (I'll call it a user). Can each user have multiple addresses (and vice-versa)? Can each address have multiple offices? Once you let us know this it will be easier to answer.
Ron
---------------------------(end of broadcast)--------------------------- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
