Move Commonly-Repeated Fields into a new Table 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!
Yes, move it.  The extra join overhead will be minimal (if the right indexes are in place!) and you will get a performance improvement for all the other queries which don't use addresses because you will get more rows per page in Customers and Offices.

Down the road, any master data management (MDM) or data clean-up will be easier with the values all in one place.

Sticky points to look out for are common definitions of column semantics (is Address4 the city, say, for absolutely every possible address?).  This could be important for reporting, for example, or summarising sales by region.  Uniqueness could be difficult to define for any natural keys you may choose to create on Addresses.