I'm still at the design stage for a new system, and I've noticed there are several places where different types of object share similar fields.
In this case, we have customers, offices, warehouses etc. that have address fields like
Address1, Address2, ... Postcode. So, I was strongly considering making a new
Addresses table with all these fields in, and an ID, and linking to that with foreign keys for all of the different types that contain addresses. The same thing could be done for groups of telephone/fax numbers too.
To illustrate this point, here's the current situation in an abstract form...
Customers Offices - CustomerID - OfficeID - FirstName - OfficeName - Surname - Telephone - Address1 - Address1 - Address2 - Address2 - Address3 - Address3 - Address4 - Address4 - Postcode - Postcode
...and after the change...
Customers Offices Addresses - CustomerID - OfficeID - AddressID - FirstName - OfficeName - Address1 - Surname - Telephone - Address3 - AddressID - AddressID - Address3 - Address4 - Postcode
The objective here isn't really normalization (I'm not intending to eliminate duplicate addresses here, even though it may be possible) but to help keep similar subtypes of data consistent. It also means that in the model code, I can treat all addresses in the same with with one class, whatever they belong to. I hope that the overhead in joining these tables wouldn't be that high, especially since I don't always need the addresses for all use cases.
Your opinions/experiences please!