Table design help

Question

I have simple table design issue which I would appreciate some feedback on. Lets say I have two tables to start: users and addresses. Both tables have their primary keys of userid and addressid. Assume no two users can share an addresss.
Is it better to have the userid in the address table, so as to associate the addresses to users OR is it better to have a third table only for associating userid's and addressid's? The latter requires an extra table but appeals to me more because the address table remains purely addresses... seems more appropriate for some reason, but I could be wrong.
Thanks

Answer 1

Frank Kulash wrote:
Hi,
When deciding which is the best option, weigh the costs and benefits of each option. What are the advantages and disadvantages of each?
The two-table model is certainly simpler. Joins will be more efficient, and slighltly less storage will be required.
What is the advantage of the three-table model? Why does it appeal to you? In the imaginary world where no two users can share an address, it makes sense to think of resident as an attribute of address. Each address can be related to (at most) one user, just like each address can be related to (at most) one postal code.
But, as others have said, that is an imaginary world. Even if you're designing an application where you know there is some kind of business rule that prevents two users from being at the same address, can you be sure that business rule won't change next month?
So I see the relevant costs ot the two-table design as: (the probablility of proving inadequate in the future) * (cost of re-writing all the queires based on the two-table design)
I see the costs of the three-table design as: extra time needed to write and execute joins + marginal costs of an additional table.
In practice, few applications really treat address as an entity. It's more common for address to be considered an attribute of the person, or, if a person can have multiple addresses, to have a separate table that links each address to a single person, with no attempt to minimize duplicates.You make two key points here that I'd like to highlight, just for re-emphasis to the OP.
The first is that business rules can change. When analyzing data relationships, one should always ask if the relationship definition is immutable or simply a reflection of the current business rule. For instance, gender is considered to be immutable. If gender is a property of the entity being tracked, you can pretty much figure that there will never be but two possible values, and only one value current at any given time. But if the business rule says an entity can only have one address ... that rule is definitely subject to change. So the design should be such as to already allow for a different rule. I spent 21 years at an auto manufacturing plant. When the plant was first built, the business rule was there would only be one line of vehicles, and only one shift a day. The IT people tried to build systems to allow more flexibility, but the business side said NO. They paid for that for the next 20 years. In the case of the OP's example, it is most definetly possible for a person (or business) to have more than one address, and it is just as possible for more than one person (or business) to share a single address. The system should be designed for that regardless of the business rule.
The other big point is that data designers need to pay close attention to what constitutes an "entity" vs. an "attribute". Making that distinction is key to getting a good 3NF design.