RE: Multi tables having a to-many relationship to the same table
RE: Multi tables having a to-many relationship to the same table
- Subject: RE: Multi tables having a to-many relationship to the same table
- From: "Rohrbaugh, John H" <email@hidden>
- Date: Thu, 27 Apr 2006 15:42:37 -0400
- Thread-topic: Multi tables having a to-many relationship to the same table
All,
Thanks for the 00 guidance. Your advice prompted me to read the
Modeling Inheritance section of my 'EOF Developer's Guide' book for a
refresher on OOing my RDB. I think I can take it from here. Thanks
again.
JohnR
-----Original Message-----
From: Chuck Hill [mailto:email@hidden]
Sent: Thursday, April 27, 2006 12:48 PM
To: Rohrbaugh, John H
Cc: email@hidden
Subject: Re: Multi tables having a to-many relationship to the same
table
Hi John,
On Apr 27, 2006, at 8:03 AM, Rohrbaugh, John H wrote:
First, a piece of advice. When you are working with EOF and start
thinking thoughts like "how to specify the changeHistoryType part of
the join", get up, take yourself outside, and give yourself a good
talking to. Think Objects not SQL. Get the Objects right, the SQL
will follow.
> We have a change history logging table named 'ChangeHistory' and
> would like several tables to have a to-many relationship to it.
>
> Student table has a to-many relationship to ChangeHistory named
> 'toStudentChangeHistory'
>
> School table has a to-many relationship to ChangeHistory named
> 'toSchoolChangeHistory'
>
> ChangeHistory includes an attribute named 'foreignKeyId' that will
> contain the primary key of the table that points to it; ie
> studentId or schoolId.
That does not make any sense in OO or RDBMS terms. Your database
will not allow you to have a FK to two different tables. In OO, you
would not want a relationship to two different classes not in an
inheritance hierarchy. At the very least your code would be littered
with casts and instanceof tests. Ugly.
Instead, let us consider this from a more OO perspective. You have a
ChangeHistory class. This is an abstract class (defines the form and
function of recording change history). There are two subclasses of
ChangeHistory that track specific types of changes. These are
SchoolChangeHistory and StudentChangeHistory. SchoolChangeHistory
extends ChangeHistory with a relationship to the School that it
records a change for. StudentChangeHistory extends ChangeHistory
with a relationship to the Student that it records a change for.
In EOModeler, we model a ChangeHistory entity and mark it as
abstract. This entity gets one additional attribute not related to
its use, type, a string of say length 10.
We then subclass ChangeHistory into SchoolChangeHistory and identify
the same table as ChangeHistory. Add an key attribute for the key of
the School. Define the school relationship. On the section page of
the Entity Inspector, we specify the restricting qualifier (type =
'School').
We then subclass ChangeHistory into StudentChangeHistory, again
identifying the same table as ChangeHistory. Add an key attribute for
the key of the Student. Define the student relationship. On the
section page of the Entity Inspector, we specify the restricting
qualifier (type = 'Student'). This will generate three Java classes
and one database table.
> Thought I would also have a ChangeHistory attribute named
> 'changeHistoryType' that would distinguish the tables (value either
> 'STUDENT' or 'SCHOOL')
>
>
See type above, call it what you want.
> toStudentChangeHistory join would be:
>
> Where Student.studentId = ChangeHistory.foreignKeyId and
> ChangeHistory.changeHistoryType = 'STUDENT'
Join Student to StudentChangeHistory in a to-many relationship based
on the Student key stored in StudentChangeHistory.
> toSchoolChangeHistory join would be:
>
> Where School.schoolId = ChangeHistory.foreignKeyId and
> ChangeHistory.changeHistoryType = 'SCHOOL'
Join Student to StudentChangeHistory in a to-many relationship based
on the Student key stored in StudentChangeHistory.
> I can not figure out how to specify the changeHistoryType part of
> the join in the EOModeler.
You need to use EOF inheritance as described above.
> Thought of a few work-a-rounds, but would rather not add
> additional attributes. For instance, could add the
> changeHistoryType to both the Student and School tables. Just
> seems like there should be a better way of doing this.
There is! :-)
Chuck
--
Coming in late 2006 - an introduction to web applications using
WebObjects and Xcode http://www.global-village.net/wointro
Practical WebObjects - for developers who want to increase their
overall knowledge of WebObjects or who are trying to solve specific
problems. http://www.global-village.net/products/practical_webobjects
_______________________________________________
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