On Nov 17, 2011, at 10:42 AM, Chuck Hill wrote: > > On 2011-11-16, at 3: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. > > I am hopeful that one of them is just in the model, you know, normal > flattening through a join table?
I thought he was saying they were both class attributes. Since they're not, they are as safe as flattening can be. Safe as far as EOF is concerned, that is. >> 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. > > Except when hiding key only join tables. In my experience key-only join tables are like not nearly as common as most developers think. Sure in a first draft of a model there's lots of key-only joins, but as the model matures and requirements and business logic becomes more clear, there is almost always another attribute to tack on there, like UserRole.status, or UserRole.type or… whatever. >> Proper relationship molding seems simple, > > Yep, just get them damp and put them someplace warm and dark. Or make it a key-only join table with a compound PK and your model will begin to rot before your eyes. >> 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) > > No foo.bar.foo? What if you have a Foo and want the Bar? Let me be more specific: don't model something where following the relationships ends you back at the *exact same instance* of an entity. Obviously you may end up back at the same Entity, but ending up at the exact same object means you've probably got something conceptually wrong in the model. >> 4) Model Inheritance only as the very last resort. > > Pfft. Use inheritance where is makes sense (Liskov sense, not for > implementation or when you really want a Role). Let me clarify. Look at all the other possibilities for modeling the relationship between to Entities first and be sure they don't apply before you chose Inheritance. I've made the mistake of jumping to Inheritance to quickly more than once (you're shocked, I know). Unlike the fabled "key-only join table", Inheritance sometimes is the right tool, but the developer should prove that two entities truly have an "is-a" relationship. "Is-a" relationships are very rigid and are difficult to change if/when you discover that it was wrong. "Has-a" relationships are much more flexible. In fact, I'll posit that inheritance really doesn't exist in the real world so modeling a relationship as such is always flawed. There are just too many exceptions. Business requirements and logic are constantly shifting. With that said, all models are flawed by definition. They are models, not true representations of the real world. That is the art of data / entity relationship / object modeling. Discovering the model that most closely represents the real world, but is flexible enough to bend and shift with the inevitable changes to requirements. Inheritance limits that flexibility. Sometimes that is actually good, though. Inheritance is much more useful as a code structure in the view and controller layer. There it is immensely useful and proper use of it usually increases flexibility and reusability. >> *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. > > True. But I want to hear more about relationship molding. I wonder if > attributes would mold too…. I'd say a class-property Foreign Keys are simply made of mold. Compound PKs and FKs mold quickly, usually due to the moist heat of shifting business requirements. Dave _______________________________________________ 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
