Re: Re: Re: SQL Joins across Subclasses

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.

Comment on Re: Re: Re: SQL Joins across Subclasses

Replies are listed 'Best First'.
Re: Re: Re: Re: SQL Joins across Subclasses by herveus (Prior) on Jan 13, 2003 at 14:15 UTC
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]
Re: Re: Re: Re: SQL Joins across Subclasses by autarch (Hermit) on Jan 16, 2003 at 05:57 UTC
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]