Please start any new threads on our new
site at https://forums.sqlteam.com. We've got lots of great SQL Server
experts to answer whatever question you can come up with.
| Author |
Topic |
|
Nick
Posting Yak Master
155 Posts |
 Posted - 2005-05-16 : 00:51:57
|
| I have a DB Design question...I have a bunch of different tables that are going to be referencing a mailing address. The tables rarely have much to do with each other, but I'm thinking a completely normalized DB design would only have one address table that related to a number of other tables.I've used this in the past and think its a little bit messy trying to maintain all of the relationships between the address table and the other tables that relate to it.So here is the question. This is an issue that I'm sure others have run into. Whats the consensus on how to do it? One address table with relationships to multiple other tables? Or multiple address tables all only related to an individual table? Or do you just put the address information into the single table?Suggestions?Thanks-Nick |
|
|
derrickleggett
Pointy Haired Yak DBA
4184 Posts |
Posted - 2005-05-16 : 01:30:22
|
| I prefer a consolidated address table for analysis, standardization, and normalization purposes. If you decide to go with multiple address tables (which you shouldn't), you need to insure you use the same columns, data types, etc in all of them. Otherwise, when you go to run reports and dig into the data later on, you are going to be beating your head against a wall.MeanOldDBAderrickleggett@hotmail.comWhen life gives you a lemon, fire the DBA. |
 |
|
|
byrmol
Shed Building SQL Farmer
1591 Posts |
Posted - 2005-05-16 : 05:12:37
|
| I'll play devil's adovcate...(goes and plays pinball)....Damn! Tilt!I don't think this has anything to do with normalisation. Normalisation only applies to a single table. Consider the entities "ClientAddress" and "SupplierAddress"..for simplicity, one client has one address and a supplier has one address..ClientID (PK)AddressLine1etc...SupplierID (PK)AddressLine1etc...What normal form has it broken? Or even more practically. Where is the redundancy? I cannot see any. The perception seems to be if there are sets of identical domains (columns) in different entities then it is not normalised. That is a myth IMO. I think it is caused be that terrible catch phrase.."One fact in one place at one time"" (or however it goes)...Extra ball!....DavidMA front-end is something that tries to violate a back-end. |
|
|
|
derrickleggett
Pointy Haired Yak DBA
4184 Posts |
Posted - 2005-05-16 : 07:46:34
|
I preferFocus David...focus. You'll get it.  Tilt! Extra ball!I have some databases that I have designed in the past and broken it out on. I "PREFER" to have one consolidated place for address and contact information. Tag.MeanOldDBAderrickleggett@hotmail.comWhen life gives you a lemon, fire the DBA. |
|
|
|
byrmol
Shed Building SQL Farmer
1591 Posts |
Posted - 2005-05-16 : 08:01:30
|
| Absolutely Derrick.... (multi-ball!)I was actual talking to the poster whos normalisation concern is a non issue.It is one of those situations where either is OK and comes down to maintainability/use/style etc...DavidMA front-end is something that tries to violate a back-end. |
|
|
|
derrickleggett
Pointy Haired Yak DBA
4184 Posts |
Posted - 2005-05-16 : 08:08:19
|
| This would be a fun pinball game. 10 balls at the same time. 3 or 4 levels. I think we agree with each other on this one.MeanOldDBAderrickleggett@hotmail.comWhen life gives you a lemon, fire the DBA. |
|
|
|
|
|
|
|
|
Mailing Address