Revisions to Database schema which can support specialized properties

replaced http://stackoverflow.com/ with https://stackoverflow.com/

edited May 23, 2017 at 12:34

URL Rewriter Bot

(Do evaluate how ProductType changes, exactly what role it plays, for each of the four Data Models.)
"Generalisation-specialisation" is all mumbo jumbo, OO terminology; without crossing the line and learning what Relational has been capable of for 30 years. If you learn a little about Relational, you will have the full power; otherwise you are limited to the very limited OO approach to everything (Ambler and Fowler have a lot to answer for). Please read this postthis post, from 11 Dec 10 onwards. Relational databases model Entities, not objects; not classes.

Fixed broken link to 5NF/6NF discussion.

Link to ▶Four Alternative Data Models◀▶Four Alternative Data Models◀ in Document Under Construction. Apologies for the mess on the floor; I will clean up soon.

Added a few words for clarity

edited Jan 6, 2011 at 21:32

Is that not clear from the data model ? ProducType CHAR(1) or (2). Name Char(330).

No. That would be a little too physical to be placed in data. Disallowed on principle. But

But it is not necessary.

given the ProductIdProductId (Subtype unknown, therefore your should not be sitting a a Subtype-specific window), load Productthe Product supertype only
based on the Discriminator Product.ProductType, set indicators, etc, and load the applicable subtype, one of ProductCPU; ProductMemory; ProductDisk; ProductTape; etc.
I have seen (and do not agree with) OO methods that load all subtypes for the given ProductId at once: one subtype is valid; and the rest are invalid. The code still has to constrain itself to the valid class for the Product based on Product.ProductType.

There may be a ProductDisk xxx, but not a ProductCPU xxx. How you handle that, whether you indicate there is a Product`xxx but it isn't a CPU, or not, that depends on the app requirements.

Is that not clear from the data model ? ProducType CHAR(1) or (2). Name Char(3).

No. That would be a little too physical to be placed in data. Disallowed on principle. But it is not necessary.

given the ProductId (Subtype unknown, therefore your should not be sitting a a Subtype-specific window), load Product only
based on the Discriminator Product.ProductType, set indicators, etc, and load one of ProductCPU; ProductMemory; ProductDisk; ProductTape; etc.
I have seen (and do not agree with) OO methods that load all subtypes for the given ProductId at once: one subtype is valid; and the rest are invalid. The code still has to constrain itself to the valid class for the Product based on Product.ProductType.

There may be a ProductDisk xxx, but not a ProductCPU xxx. How you handle, whether you indicate there is a Product`xxx but it isn't a CPU, or not, that depends on the app requirements.

Is that not clear from the data model ? ProducType CHAR(1) or (2). Name Char(30).

No. That would be a little too physical to be placed in data. Disallowed on principle.

But it is not necessary.

given the ProductId (Subtype unknown, therefore your should not be sitting a a Subtype-specific window), load the Product supertype only
based on the Discriminator Product.ProductType, set indicators, etc, and load the applicable subtype, one of ProductCPU; ProductMemory; ProductDisk; ProductTape; etc.
I have seen (and do not agree with) OO methods that load all subtypes for the given ProductId at once: one subtype is valid; and the rest are invalid. The code still has to constrain itself to the valid class for the Product based on Product.ProductType.

There may be a ProductDisk xxx, but not a ProductCPU xxx. How you handle that, whether you indicate there is a Product`xxx but it isn't a CPU, or not, that depends on the app requirements.