The answer here is: "It Depends." And as Justin said, use your best judgment.
There is nothing wrong with just storing the ID of the parent Country / Site. Most likely it is in fact a foreign key in the child table. On the other hand, putting the parent Country / Site object in there may be necessary. A City may need to reference a property of the Country such as what hemisphere the country is in or a federal law. Likewise a Page may need to reference Site-wide variables such as the secure URL or whatever. Another way to look at it would be that if the child object is a transient and does not need anything related to the parent, then don't bother putting it in there. But if both are singletons, there is no significant additional overhead to putting a reference to the parent in the child, so go for it. Again it depends on your use case and use your best judgment. The worst case scenario for doing that is some refactoring, which can be a good exercise anyway. Matt Williams On Feb 20, 4:01 pm, Henry Ho <[email protected]> wrote: > Let me try to explain with another example. > > A Country has many City. > > So.. let's say I want to create a new City. In order to be a valid > city, it has to belong to a Country. However, if the City has no > behaviour that requires Country, does it make sense to have City carry > a reference to Country? > > The system, (through use of singleton) must be able to answer which > city belongs to which country, but City object itself does not. > > Thanks, > Henry Ho > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "CFCDev" 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/cfcdev?hl=en -~----------~----~----~----~------~----~------~--~---
