Just to clarify, I use a one to many relationship from Person to Role so that I
can add additional data for that person’s role to the Role entity. If this is
not necessary, many to many works well.
In my case (where each Role has additional data), the Role being a super-entity
with single table inheritance is not very scary. The big win is, you can do
this:
Role
SupervisorRole
WorkerRole
ContractorRole
Person —>> Role
With single table inheritance, you don’t end up with the performance penalties
of other inheritance structures, and since there will only be at most a few
objects per Person, it shouldn’t be a burden.
One other point - this structure allows you to have a startDate and endDate in
the Role entity, and then you can support the idea that a person could have the
same role multiple times in their career, like:
ContractorRole 1-1-2013 5-1-2013 Company:Acme
Consulting
SupervisorRole 5-2-2013 5-1-2014
Department:Widget Assembly
ContractorRole 5-2-2014 NULL Company:Joe’s Consulting
This gives a natural audit trail - and you can put a method in the Person class
that only returns current role(s).
Ken
On May 20, 2014, at 4:55 AM, David Avendasora <webobje...@avendasora.com> wrote:
> Ted,
>
> I agree 100% with Ken. Inheritance is the *wrong* thing to use in this
> situation. Using a Role with a many-to-many relationship to Person is the
> right way to do what you want. What is especially great about this pattern is
> that it makes it easy to switch what role(s) a Person has at runtime
> depending on the current context you are using them in. The Role entity
> itself could use inheritance if need-be, but in general I avoid using
> inheritance. It certainly is the right thing to do sometimes but be very
> cautious.
>
> Dave
>
> Sent from my iPhone
>
> On May 19, 2014, at 4:10 AM, Ken Anderson <kenli...@anderhome.com> wrote:
>
>> I’m not familiar with ERXPartials, but I would second the use of a role
>> pattern. I typically use this pattern for both people and companies.
>>
>> To elaborate, you can have a table/entity - Person. You then have a number
>> of Role entities (WorkerRole, SupervisorRole) that inherit from a Role
>> entity, where WorkerRole, SupervisorRole, and any other roles, use a single
>> table (single table inheritance). Then you have a to-many relationship from
>> Person to the Role entity.
>>
>> You can use validation to enforce any business rules you have (like a person
>> can’t be both a supervisor and worker at the same time).
>>
>> In this manner, you can have all the immutable attributes of a Person in one
>> place, and all their role data (like maybe the supervisor’s head count) in
>> the role where it makes sense.
>>
>> An important downside of a Person entity with a sub entity of Worker and
>> Supervisor - what happens when the worker gets promoted? EOF HATES IT if
>> you try and modify the entity of a particular object. That means that you
>> end up deleting John the Worker and adding John the Supervisor, destroying
>> any history you had of John (like to pay records, infractions, etc).
>>
>> Good luck!
>>
>> Ken
>>
>> On May 12, 2014, at 2:50 AM, Timothy Worman <li...@thetimmy.com> wrote:
>>
>>> Ted:
>>>
>>> Rather than inheritance, I use ERXPartials for this. Have one database
>>> entity for ‘Person’ and various types of persons as partials. One database
>>> row has all of the attributes of the different types.
>>>
>>> If not partials, I probably prefer the role pattern to inheritance.
>>>
>>> Tim
>>> UCLA GSE&IS
>>>
>>> On May 11, 2014, at 1:02 PM, Theodore Petrosky <tedp...@yahoo.com> wrote:
>>>
>>>> I am starting a project. I need to manage assets (people). But people will
>>>> be both a User of the system and the managed asset.
>>>>
>>>> Also a person could be an employee of a company that needs to manage the
>>>> assets.
>>>>
>>>> So I thought I would create a person class and do inheritance.
>>>>
>>>> a worker inherits from a person
>>>> a supervisor inherits from a person
>>>>
>>>> Am I going nuts and too deep with inheritance? Would it be easier to have
>>>> a single entity person that has booleans to identify workers or
>>>> supervisors. I mean a person could be both a worker and supervisor.
>>>>
>>>> maybe just talking about it will help me think if through.
>>>> _______________________________________________
>>>> 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:
>>>> https://lists.apple.com/mailman/options/webobjects-dev/lists%40thetimmy.com
>>>>
>>>> This email sent to li...@thetimmy.com
>>>
>>>
>>> _______________________________________________
>>> 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:
>>> https://lists.apple.com/mailman/options/webobjects-dev/kenlists%40anderhome.com
>>>
>>> This email sent to kenli...@anderhome.com
>>
>> _______________________________________________
>> 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:
>> https://lists.apple.com/mailman/options/webobjects-dev/webobjects%40avendasora.com
>>
>> This email sent to webobje...@avendasora.com
_______________________________________________
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:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
