Actually, it sounds like a case of what CJ Date calls the "First Great Blunder", which is equating object classes with tables (as opposed to domains/data types).
Date would probably suggest using three tables (common attributes in one, unique attributes in two others) and views to solve the problem that was originally posted. Unfortunately, no RDBMS today supports proper (always updateable) views, AFAIK.
| [reply] |
What do you mean by "equate", and why is that a blunder? Our design for this object-oriented API is generally to allocate a separate table to each class that requires persistence. More specifically, if a class has a one-to-one relation with a particular attribute, that attribute gets a place in the table for the class. If there is a one-to-many relation then we have a separate table for the attributes, keyed to and constrained by a unique id in the class's primary (parent) table. If this is what you're suggesting is a blunder, I'm wondering what terrible fate should have befallen us in the previous four years of development :^)
As to the rest of your comment, I'm leaning toward the three table layout, although since the subclasses in my object model will require all of the contents in Asset and all of the contents in either DocumentAsset or MediaAsset, a join I think is more appropriate than a view. I think of views as more for taking a subset of data from several tables, but this is really a combination of everything keyed to a unique id.
| [reply] |
Howdy!
Let me give you a shove to increase your lean :)
Since you are clearly working with an RDBMS for your
store, you really do want to have a relational model for
your data that is fully normalized. Since you note elsewhere
that this application will not involve either a huge
database or high transaction rate, you probably do not
need to spend resources on premature optimization.
So long as your classes properly assemble the data, the
outside world has no need to know what wizardry goes on
under the hood.
yours,
Michael
| [reply] |
What do you mean by "equate", and why is that a blunder?
You mean to ask "what does CJ Date mean?" I'm just paraphrasing him. The blunder is to try to treat object classes as relational tables, as opposed to treating object classes as data types (domains, or "column types") in the RDBMS. Of course no SQL DBMS on the market supports proper user-defined domains, so there's no way you can do what he wants with any existing product (which is part of his point ;)
I'd recommend The Third Manifesto (make sure to get the 2nd edition, not the 1st) by CJ Date and Hugh Darwen if you're interested in more details.
| [reply] |