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 |
|
MikeB
Constraint Violating Yak Guru
387 Posts |
 Posted - 2008-09-11 : 07:55:01
|
I am developing a database system and was wondering how to handle addresses? In a previous database I normalized the geographical locations with the following:Cities CityId, City, RegionIdRegions RegionId, ProvinceCodeProvincesProvinceCode, CountryCode, ProvinceCountriesCountryCode, Country In a companies table, I stored the CityId for its geographical location. The problem is that every time I needed to get the company information, I had to join the above tables to get the City, Region, Province, and Country.That is 4 table joins. For just getting the company information it was fast, but for some other queries where numerous other joins are required, this is just another 4 table that may add to slowing down the queries.My question is, should I just keep the structure above and use it as a "LOOKUP" table and store the actual City, Region, Province, Country in tables like the Companies table or should I keep the normalized structur and just save the CityId.Hope this was clear?Mike B |
|
|
LoztInSpace
Aged Yak Warrior
940 Posts |
Posted - 2008-09-11 : 20:26:49
|
| You say this 'may add to slowing down the queries'. Did you actually measure it against a denormalised version?I'd hazard a guess that given the relative size of most state/province tables it makes little or no difference if your stats are all good. Databases are there to do this stuff and I would be suprised if something like this seriously affected performance. If you find you do need to then I'd suggest an indexed view, but measure it first and determine where your CPU/IO is actually being burned. |
 |
|
|
|
|
|
|
|
City/Province/ etc... Normalize?