Re: Parallel structure EO modeling
Re: Parallel structure EO modeling
- Subject: Re: Parallel structure EO modeling
- From: Philippe Rabier <email@hidden>
- Date: Tue, 26 Feb 2013 23:59:14 +0100
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@hidden> 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@hidden)
>>> Help/Unsubscribe/Update your Subscription:
>>>
>>> This email sent to email@hidden
>>
>
>
> _______________________________________________
> 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
_______________________________________________
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