• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Subclass conflict with single-table mapping?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


References: 
 >Re: Subclass conflict with single-table mapping? (From: email@hidden)
 >Re: Subclass conflict with single-table mapping? (From: Drew Thoeni <email@hidden>)
 >Re: Subclass conflict with single-table mapping? (From: Chuck Hill <email@hidden>)

  • Prev by Date: Re: SQL generation 'create index null'?
  • Next by Date: Re: stringQualifierOperators (like, contains)
  • Previous by thread: Re: Subclass conflict with single-table mapping?
  • Next by thread: Re: Subclass conflict with single-table mapping?
  • Index(es):
    • Date
    • Thread