|
|
Posted by Hugo Kornelis on 09/30/29 11:17
On 31 May 2005 01:40:30 -0700, martind-crap1@mailblocks.com wrote:
>Thanks for the input, guys! I'm looking to go for maximum flexibility
>without having to abandon 1-to-n in favor of n-to-m, so here's another
>option I'm contemplating: What if I include a discriminator in
>Employee that specifies whether the parent_id references an Agency or a
>Publisher? Foreign key constraints are no longer possible, but hey,
>can't have it all...
Hi Jen,
I don't like this idea. Don't mess up your referential integrity. Some
day, it will bite you - and it'll bite you HARD.
I still recommend using a supertype. And if the entities are really
totally unrelated, then I'd use seperate columns (as shown in my
previous post) for the relationships.
I don't understand the "abandon 1-to-n in favor of n-to-m" part of your
message - how does my proposed design abandon 1-to-n?
Final note: if you have to expand my design to have more than two
mutually exclusive 1-to-n relationships, then you might wish to rewrite
the CHECK constraint to a more expandable form:
CHECK ((CASE WHEN AgencyCode IS NULL THEN 1 ELSE 0 END
+ CASE WHEN PubNum IS NULL THEN 1 ELSE 0 END
-- room for expansion is here
) = 1)
>One specific case are Address objects, which I want to back-link to
>their respective owners (Agents, Publishers, Customers, Suppliers, etc.
>all have addresses, and I can't find a good superclass that won't screw
>up my ORM).
Aren't Agents, Publishers, Contacts and Suppliers all Relations? Or
(depending on your business) Roles of Relations?
Best, Hugo
--
(Remove _NO_ and _SPAM_ to get my e-mail address)
Navigation:
[Reply to this message]
|