In my application I have a Customer
class and an Address
class. The Customer
class has three instances of the Address
class:
I have this in Zen Cart (and probably osCommerce as well), in the orders table and wondered why they went that way, even more as they have an addresses table.
The only reason I saw, which is valid, is for record purposes: even if the customer changes their addresses, the order information must not change, it reflects the data at the time of the order.
Now, it is a bit wasteful, even more if the same customer does lot of orders. A possible solution is to keep an history of addresses and reference them with the orders.
I wonder if these immutable addresses (or mutable if they have no related order yet) should be kept in the regular address book or in a separate, history table, filled in only if an order is made (avoiding duplicates if the same customer keep the same address, of course).
The former has the advantage of avoiding to have two tables of very similar structures and duplicated information, but might hinder performances (?) as history grows. Although people rarely change this information, in practice.
The latter has the advantage of separating roles (one is immutable, not the other), the history being rarely used.
Overall, if you application doesn't need to keep an history, just go for two separated tables.