This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
This is something I have always encountered while creating a data model to fit a class diagram. A simple scenario to consider is : A customer, a credit card and a Payment class. For simplicty a customer has got one credit card, can have many orders and pays them with his single credit card. A credit card can belong to a payment object and also to a customer. In terms of storing them in database, both has to be stored in different tables. Why ? Cause a payment object cannot just point to the customers credit card. A payment object should point to a credit card that was used while paying. However the credit card details associated with the customer can change over time. I have got two options : 1. Store them in the same table but in different rows representing different objects. In this case we can assoicate the same class to customer and payment. 2. Create two different classes i) Customer Credit Card ii) Payment Credit Card and persist them in different tables. Which option is better and why? [ April 16, 2004: Message edited by: Anjan Pathak ]