I'm currently sketching out an object model where I have a superclass that holds about five attributes shared among the subclasses, with a couple of attributes in each subclass that are unique to it, and I'm trying to decide on a good relational table layout for the classes. In the past I've sometimes found it more worthwhile to have a single table that all the classes shared, just so long as their differences where minor and their unique attributes were not mutually exclusive. In other cases, where there was more difference than commonality, I've had entirely separate tables for each subclass. In this case though, I've got the bulk of the attributes shared and implemented in the superclass, with a minority of class-specific, and mutually exclusive attributes in the subclasses.
Note: a concrete subclass will have both an asset_id and either a doc_id/label or media_id.Asset attributes: asset_id desk status priority deadline / \ DocumentAsset attributes: MediaAsset attributes: doc_id media_id label
My question is whether it makes sense to break this out into three tables and use joins to assemble the data into an object instance, or combine them into a single table where the doc_id, media_id, and label fields can be NULL (since you can have at most two of the three at any time)? Perhaps set up constraints that prohibit any one row from having values set for both doc_id and media_id?
Thanks for your input, fever
In reply to SQL Joins across Subclasses by djantzen
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |