On Nov 10, 2011, at 5:34 AM, Paul Hoadley wrote: > Say I have two entities, User and Role, and a joining entity UserRole to > create a many-to-many relationship between them. So I have a relationship > 'userRoles' from User to UserRole (and a relationship 'userRoles' from Role > back to UserRole). I flatten the relationship on User, so I also have a > 'roles' relationship on that entity.
Wait. "Also"?!? That's insane. That's two distinct relationships representing the same DB information, and one is hiding a huge piece of the action. You are just asking for trouble. Pick one. Get rid of the other. I vote for getting rid of the flattened relationship. I find flattened relationships to be on the same level as compound PKs. Sure they seem great, but eventually they come back to bite you. They paint you into a long-term corner for short-term convenience sake. Proper relationship molding seems simple, but it is full of subtleties and complexities and you can easily do things that work fine in all but a few specific conditions and then they can corrupt your data without you knowing it until it's too late. Having two relationships that represent the same information makes database corruption at least 10x more likely. Here's "Dave's Rules of Happy Modeling™" * 1) No flattened relationships 2) No compound primary keys 3) One path to data (no cyclical relationships) 4) Model Inheritance only as the very last resort. *Oftentimes you are stuck with an existing/legacy DB and it is great that WO gives you the tools to work with a sub-optimal (from an OO perspective) architecture, but you should be very hesitant to use those tools when creating a new architecture. _______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
