Re: Delete rules on flattened relationships
Re: Delete rules on flattened relationships
- Subject: Re: Delete rules on flattened relationships
- From: Chuck Hill <email@hidden>
- Date: Wed, 16 Nov 2011 18:42:30 -0800
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?
> 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.
> Proper relationship molding seems simple,
Yep, just get them damp and put them someplace warm and dark.
> 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?
> 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).
> *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....
Chuck
--
Chuck Hill Senior Consultant / VP Development
Practical WebObjects - for developers who want to increase their overall knowledge of WebObjects or who are trying to solve specific problems.
http://www.global-village.net/products/practical_webobjects
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden