On Nov 16, 2011, at 4:38 PM, David Avendasora wrote: > > 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.
Third normal form. Every non-key attribute must provide a fact about the key, the whole key, and nothing but the key... so help me Codd ;-) > > 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. Dave, Dave, Dave.... you have to have flattened relationships for Vertical Inheritance! *ducks* (^^) You forgot some good ones too. Magic numbers (PK 0), natural keys (SSN), non-atomic fields (name "Mary Jones"), omitting FK constraints... Ramsey _______________________________________________ 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
