Ramsey, Well, this really isn't a business rule - it's basically just that data will be separated by Male/Female, and you would never attach a Male version of something (like a workout) to a female customer. I like it when the model enforces data validity in that way, but I think it's just too much trouble to have triple the number of entities (M/F/abstract) to make it work.
Thanks, Ken On Feb 26, 2013, at 3:38 PM, Ramsey Gurley <[email protected]> wrote: > Can you give a concrete example illustrating what you mean? Generally I stay > away from enforcing business rules with the schema. When business rules > change, as they always do, you're boned. I use the schema to enforce data > integrity. > > Ramsey > > On Feb 26, 2013, at 1:11 PM, Ken Anderson wrote: > >> All, >> >> I have a difficult decision to make and am waffling back and forth. I'm >> hoping some of you guys might have come across a similar situation and would >> have some recommendations. >> >> I have a model where a number of entities can by applied only to males or >> only to females (it's an exercise app). Part of me wants to create >> sub-entities called "Male…" and "Female…" because EOF will effectively >> validate relationships for me. Unfortunately, it's a pretty deep entity >> hierarchy and there would be a lot of entities that would have to fall into >> this category. Not to mention there are join tables that wouldn't have an >> M/F flag, but to stay consistent would have to be subclassed as well. >> >> Any thoughts? I would do them all with single table inheritance, so there >> wouldn't be much of a performance hit. >> >> Thanks, >> Ken >> >> >> _______________________________________________ >> Do not post admin requests to the list. They will be ignored. >> Webobjects-dev mailing list ([email protected]) >> Help/Unsubscribe/Update your Subscription: >> https://lists.apple.com/mailman/options/webobjects-dev/rgurley%40smarthealth.com >> >> This email sent to [email protected] > _______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [email protected]
