Hi Ken, Could you imagine an app for male and another one for female?
If that case, you could create your model where table name have _male as suffix, use it as this in the WOApp for males and with a property file, change the table names dynamically with, by convention, _female as suffix in the WOApp for females. Your model is unique, it's just the database that is different for male and females. You can do so very easily using wonder if you put some properties like this one: er.extensions.ERXModelGroup.Entity1.externalName=Entity1_FEMALE er.extensions.ERXModelGroup.Entity2.externalName=Entity2_FEMALE ... And you can have common entities if you are using the same database. Philippe On 26 févr. 2013, at 22:45, Ken Anderson wrote: > 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/prabier%40me.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]
