Re: Subclass conflict with single-table mapping?
Re: Subclass conflict with single-table mapping?
- Subject: Re: Subclass conflict with single-table mapping?
- From: Ian Joyner <email@hidden>
- Date: Wed, 14 Dec 2005 12:48:26 +1100
On 13/12/2005, at 12:19 PM, Chuck Hill wrote:
On Dec 12, 2005, at 4:59 PM, Drew Thoeni wrote:
See below...
On Dec 12, 2005, at 7:12 AM, email@hidden wrote:
What is the primary key of your Employee table?
employeID (long integer)
Does the database's primary key definition match with what you
declared in EOModeler?
Yep. Using Frontbase LONGINT
Can you be sure no Client shares a primary key with an Consultant?
Just have test data (only a few rows), so I've been able to verify
that there are no duplicate keys. However, some clients are also
consultants so they share a type. Client alone is type==1,
consultant alone is type ==2, an employee who can be a client or
consultant is type==3.
Um, that is NOT inheritance. There is no "some" in inheritance.
Either _all_ clients are also consultants or _no_ clients are also
consultants. Java won't do this, neither will EOF. I can't think
of any language that does, but there are probably some, somewhere.
Maybe BETA:
http://www.daimi.au.dk/~beta/
but it's been a while since I looked at it, but from memory it was
very flexible and dynamic.
You could make a third subclass, ClientConsultant, but I think you
are just heading into the Land of Hurt doing that.
You need to get rid of inheritance. Take a look at the Role
pattern (first Google hit http://www.geocities.com/tablizer/
prpats.htm#role). Or just infer it by the relationships.
Yes, sounds like you want to model it with n:m join tables. That way
an employee is a consultant iff a record exists in the project ->
consultant join table, and an employee is a client iff a record
exists in the project -> client table. You can also include
attributes about the project -> consultant and project -> client join
tables, attributes that don't make sense on either the employee
entity or project entity alone (for example project role). I think
this reflects 'could-be' design, rather than just 'is-a' design.
In this way relational modelling (not necessarily ER) is more
powerful and dynamic than OO modelling because you can deduce facts a
postiori rather than a priori. (I know send round the OO lynch mob now!)
Ian
_______________________________________________
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