David, There’s no many-to-many in my implementation, since the Role is defined by the chosen sub-entity - I don’t have a record representing the Role itself. So, it’s a one (Person) to many (Role sub-entity).
Ken On May 24, 2014, at 11:51 AM, David Avendasora <webobje...@avendasora.com> wrote: > Hi Ken, > > How is what you're describing below not a many-to-many where the join table > (PersonRole) has their start date, end date and other data that is specific > to that particular combination of person and role? It also allows for > concurrent assignment of multiple roles. > > I do agree that in almost all circumstances using inheritance for the role so > each subclass isa Role is the right way to go. Sometimes you can get by with > an interface but usually inheritance is the way to do it. > > I think we're describing the same thing but using different terms for it. But > are we? > > Dave > > Sent from my iPhone > > On May 21, 2014, at 2:39 AM, Ken Anderson <kenli...@anderhome.com> wrote: > >> 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
