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
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
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
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
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
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
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 GSEIS
On
