In my application I have a Customer
class and an Address
class. The Customer
class has three instances of the Address
class:
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.