 | |
primary key as subtype discriminator
comp.databases.theory comp.databases.theory
 |
| | Thread Tools | Display Modes |
#51
 
| |||
| |||
|
Re: primary key as subtype discriminator -
09-05-2008
, 12:08 PM
|
On Sep 3, 2:37*am, jefftyzzer <jefftyz... (AT) sbcglobal (DOT) 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. |
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
#52
| |||
| |||
|
|
On Sep 3, 2:37*am, jefftyzzer <jefftyz... (AT) sbcglobal (DOT) 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. |
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
#53
| |||
| |||
|
|
On Sep 3, 2:37*am, jefftyzzer <jefftyz... (AT) sbcglobal (DOT) 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. |
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
#54
| |||
| |||
|
|
On Sep 3, 2:37*am, jefftyzzer <jefftyz... (AT) sbcglobal (DOT) 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. |
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
#55
| |||
| |||
|
|
On Sep 3, 2:37*am, jefftyzzer <jefftyz... (AT) sbcglobal (DOT) 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. |
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
|
« Previous Thread
|
Next Thread »
| Thread Tools | |
| Display Modes | |
Linear Mode
| |
Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.