Three customer addresses in one table or in separate tables?

Question

In my application I have a Customer class and an Address class. The Customer class has three instances of the Address class:

Answer 1

I'd go with denormalized. It's easier.

If you normalize it, the address table would require you to remove duplicates and relink records from the customer table. If I had the same delivery and invoice address, it seems like it should link to the same record. If I change one, you're required to:

1. Create a new address record.
2. Relink the customer record.

If I change it back you need to check:

1. Does a similar address entry already exist.
2. Relink the customer record.

This programming overhead seems to obviate the advantage of less space that normalization seems to offer. A denormalized solution, like you pointed out, would provide faster queries and easier maintenance (programming-wise). This seems to be the deciding factor for me.

A normalized solution, like pointed out above, would allow you to add more addresses later. But you'd have to add a field for the foreign key anyways, unless you planned on organizing the tables without linkage from the customer to the address table.

Advantages of Normalized

• Less space.
• Duplicate logic kinda built in (though maybe they weren't actually duplicates?)
• Support addition of new address fields (kinda).

Advantages of Denormalized

• Faster queries.
• Less programming.

Answer 2

Go with 2 tables, Customer, Address.

Once addresses have been created in the address table do not ordinarily allow them to be modified (perhaps a specific tool to correct typos). IOW make the ID of the address idempotent with the address itself.

You can now reference these address table entries anywhere. For example when an order is dispatched to a customer the address ID that is referenced a by an Order table can be the same one as in the DeliveryAddressID field in the customer table.

If the customer wishes to change the currently on file delivery address to a new one, a new address record is created. The historical delivery data is unaffected by this yet new orders automatically use the new address.

Note this is also helpful when caching Addresss objects (they're immutable and are safe for long term caching), they can be distributed and more easily tested for equality (via the ID property).

Answer 3

My two cents is that de-normalizing the way you describe is OK, if you have a compelling reason. Sometimes that reason can be as simple as a high level of confidence you will never need the normalized form. As Stefan Mai implied, it's much easier to just retrieve and update a single table, if you only ever need to work with the three types of addresses you indicated. On the other hand, if the three addresses requirement has any possibility of changing then it probably will, and early-on is the better time to normalize.

Answer 4

In this case, putting each address field in a different row is not normalization. It's just table partitioning. The assumption that any schema with more tables is "more normalized" is wrong.

Let's say we have these two alternative schemas in a database: 1) user: user_id, username, password

2) user: user_id, password_id password: password_id, password

Is (2) "more normalized" than (1)? No!

In this OP's case, as long as: 1) we're treating the address as an atomic value, 2) the application only requires those three types of addresses.

Then it is just as valid valid to store each address in a different column. The second solution does not decompose the addresses into its components (country, town, street, etc). Therefore it is not "more normalized" than the first one!

Answer 5

I'd go (as database theory teaches) for two separate tables: Customer and Address.

The idea of putting three fields in the Customer table is bad, as you say, because it would violate normalization rules (and fail when addresses would become more than three).

edit: also, I'd split the Address table record in several fields, one for the toponomastic prefix, one for the street, etc. and put a unique key on those. Otherwise, you'd end with a database full of duplicates.

Answer 6

If you are 100% certain that a customer will only ever have the 3 addresses you described then this is OK:

CREATE TABLE Customer
(
    ID int not null IDENTITY(1,1) PRIMARY KEY,
    Name varchar(60) not null,
    customerAddress int not null
        CONSTRAINT FK_Address1_AddressID FOREIGN KEY References Address(ID),
    deliveryAddress int null
            CONSTRAINT FK_Address2_AddressID FOREIGN KEY References Address(ID),
    invoiceAddress int null
            CONSTRAINT FK_Address3_AddressID FOREIGN KEY References Address(ID),
    -- etc
)

CREATE TABLE Address
(
    ID int not null IDENTITY(1,1) PRIMARY KEY,
    Street varchar(120) not null
    -- etc
)

Otherwise I would model like this:

CREATE TABLE Customer
(
    ID int not null IDENTITY(1,1) PRIMARY KEY,
    Name varchar(60) not null
    -- etc
)

CREATE TABLE Address
(
    ID int not null IDENTITY(1,1) PRIMARY KEY,
    CustomerID int not null
        CONSTRAINT FK_Customer_CustomerID FOREIGN KEY References Customer(ID),
    Street varchar(120) not null,
    AddressType int not null 
    -- etc
)