Re: primary key as subtype discriminator

On Sep 4, 6:12 am, philiptaylo..._at_yahoo.com wrote:
> On Sep 3, 2:37 am, jefftyzzer <jefftyz..._at_sbcglobal.net> wrote:
>
> > I think that's a bad idea. I know this may sound a bit shop-worn, but
>
> Hi Jeff, thanks for your answer. I think that's a bad idea too, but
> for different reasons. In my opinion the compound PK in the subtypes
> becomes "redundant". You always know the value of part of the PK given
> a subtype. I see this like a normalization error.
>
> > all subtypes should be mutually exclusive and exhaustive. Further,
>
> You can use a role entity to relax the mutual exclusivity requirement.
>
> > they should each describe a semantically unique "kind of" the
> > supertype, with each subtype described by attributes unique to it.
> > vs. smart key vs. surrogate key holy war. Besides, if the PK is, say,
> > a 4-byte unsigned integer, are you saying you'd have (in order to
> > satisfy the "exhaustive" property) 4,294,967,296 subtypes?
>
> What if, for instance, PK BETWEEN 1 AND 5? You are considering the
> whole 4-byte unsigned integer domain without constraints. Moreover I
> could use a natural key as category discriminator.

You're right, using a 1:M role is a great way getting around the mutual-exclusivity requirement (assuming that's what the business rules dictate). Your point in re: the integer is also well-taken: I should have said "up to 4,294,967,296 subtypes," but regardless, it was still a bit of an exaggeration.

Regards,

--Jeff Received on Fri Sep 05 2008 - 19:08:28 CEST