Re: Multiple many-to-many with single-table inheritance
Re: Multiple many-to-many with single-table inheritance
- Subject: Re: Multiple many-to-many with single-table inheritance
- From: Drew Thoeni <email@hidden>
- Date: Sun, 4 Dec 2005 13:57:38 -0500
David,
Thanks. Upon researching this more, and contemplating your option #2,
it seems that what would really suite the needs of this problem is
"single-table mapping."
http://developer.apple.com/documentation/WebObjects/UsingEOModeler/
7ModelingInheritance/chapter_7_section_5.html#//apple_ref/doc/uid/
TP30001018-CH207-CACJFAHB
I'm giving that a shot and will see how well it works. One oddity
about this is that an employee can be more than one of these things
(they can be a project owner on one project, and a project manager on
another. So I'm using a type code as part of the qualifier that
allows the employee attribute of "type" to have a coded integer value
where 1=owner, 2=consultant, 4=manager. This allows for a type of 3 =
owner or consultant.
What I'm trying to do is build a pop-up list showing only those
employees that could possibly be a consultant. The qualifier for the
consultant subclass is ((type=2) or (type=3)).
Drew
On Dec 4, 2005, at 2:37 AM, David Avendasora wrote:
I don't believe you need 3 many-to-many joins. There are three
different ways to handle this each with their own benefits/drawbacks.
1) Three to-one relationships:
- With the classes and attributes that you already have, create the
following to-one relationships
- Project.projectOwnerID -> Employee.employeeID
- Project.consulatantID -> Employee.employeeID
- Project.projectManagerID -> Employee.employeeID
The benefit of this method is that it is very easy to get the
related objects with getOwner() getProjectManager() etc. but this
restricts you to only one of each Owner, Consultant and Manager
(which may be valid for Owner and Manager, but almost certainly not
for Consultant).
2) One Many-to-Many relationship:
- Remove the three Employee attributes from the Project class.
- Create an intermediate class of ProjectEmployee with the
following attributes
- projectEmployeeID (PK)
- projectID
- employeeID
- projectEmployeeTypeID
- Create type class of ProjectEmployeeType with the following
attributes
- projectEmployeeTypeID
- typeName
- Create the following to-many relationships
- Project.projectID -> ProjectEmployee.projectID
- Employee.employeeID -> ProjectEmployee.employeeID
- ProjectEmployeeType.projectEmployeeTypeID ->
ProjectEmployee.projectEmployeeTypeID
- Create the following to-one relationships
- ProjectEmployee.projectID -> Project.projectID
- ProjectEmployee.employeeID -> Employee.employeeID
- ProjectEmployee.projectEmployeeTypeID ->
rojectEmployeeType.projectEmployeeTypeID
This gives you the most flexibility and the most "normalized"
database. You can have any number of Owners, Consultants and
Managers (may or may-not fit your business-logic) and you can
easily add new "types" of employees to the Project-Employee
relationship by simply creating new types. There's no need to
change the data-structure or the classes.
The drawback is that it makes the simple things like
Project.getOwner() method more involved because this method will
not exist unless you create it. You will have a getEmployees()
method and you'll need to modify it so you can pass the type you
are requesting line getEmployees("Owner") or something like that.
Again, you can write individual methods like getOwner() to hide
this extra work, but it is work you wouldn't need to do if you used
to-one relationships.
3) One (or two) to-one relationships and one to-one relationship.
- If you KNOW you will only have one owner and/or one Manager, then
- keep those relationships as to-one as outlined above in option 1
- make the Consultants relationship to-many as outlined in option
2 (Eliminate the ProjectEmployeeType class and relationships)
This gives you easier to read and understand object and data models
and code, but is still quite inflexible.
I personally almost always use option 2 as it reduces the impact of
most common changes to the system that that WILL happen. When your
customer decides that you really need to have multiple Owners or
that each Project also has a Business Analyst or that Consultant is
just too generic. Option 2 makes all of these changes trivial where
options 1 and 3 force you to make major changes to the classes and
database. Up-front it's a little more work, but in the long run, it
will save you a LOT.
Hope this helps!
Dave
On Dec 4, 2005, at 5:00 AM, Drew Thoeni wrote:
I have a set of two objects:
Project
Employee
The Project has three attributes that relate to Employee:
projectOwnerID
consultantID
projectManagerID
I'd like to use single-table inheritance and have Employee with
children.
It is unclear to me how to create three many-to-many joins in
EOModeler between the two Objects (Project and Employee).
Is this possible? I can create the first one using "Join in Many-
to-Many", but adding the next fails as EOModeler has already
created a flattened relationship for "projects" and "employees."
The best idea I have is to rename the relationships from
"employees" to "owners", "consultants", and "projectManagers" and
rename the other side as "ownerProjects", "consultantProjects",
and "projectManagerProjects."
Is this the proper method?
Regards,
Drew
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40avendasora.com
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