Martin Schapendonk wrote: > Or maybe I could solve this with a PersonAddress and > OrganizationAddress based on the same table? However, that would > violate DRY, because those models are going to be very, very similar.
Martin: If you have ever had a chance to take a look at larger scale data warehouses (PeopleSoft, Oracle, Siebel, etc.) you will find that the designers quite often create a different set of address tables for contacts and organizations. Don't feel bad for doing it. Contacts and organizations are very different entities and trying to combine their respective addresses into one table is bringing your database to a state of non-normalization and you are more likely to end up with insertion anomalies and the like. Another option is to keep organizations and contacts in a separate tables and move the relationship to addresses out to a many-to-many join table that intersects with an address table. I don't usually take this approach because I think it is often more work than it's worth. You obviously have a number of options at your disposal, depending on what your criteria are. Cheers, Matt -- BASIC: A programming language. Related to certain social diseases in that those who have it will not admit it in polite company. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Cake PHP" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cake-php -~----------~----~----~----~------~----~------~--~---
