Re: Object-oriented thinking in SQL context?
Date: Wed, 17 Jun 2009 11:34:55 -0400
Message-ID: <D28_l.32$OF1.1_at_nlpi069.nbdc.sbc.com>
"Nilone" <nilone_at_mega.co.za> wrote in message
news:1245239158.868623_at_vasbyt.isdsl.net...
> "Bob Badour" <bbadour_at_pei.sympatico.ca> wrote in message
> news:4a2ee2f5$0$23770$9a566e8b_at_news.aliant.net...
>> none Reinier Post wrote: >> >>>>>>In my first post: >>>>> >>>>>>"I have a problem with wrapping my mind into the 'right' wrinkles." >>>>> >>>>>>"The [system] would be almost trivial to implement in an >>>>>>object-oriented context [...], >>>>>>but I don't see how to come up with a table-based database >>>>>>design." >>> >>> >>> Think 'class' ~ 'relation' (table) >> >> But that would not only be a blunder but a great blunder. >
> I'd like to clarify this for anyone coming from the OO side. If you map
> class to relation, you're breaking the OO rule of encapsulation and
> reducing the class to a simple aggregate type (struct). Presumably, you
> chose an encapsulated, polymorphic abstraction device for a reason, or did
> you do so just because you (or somebody at your company) read Lhotka's
> book? Classes map to domains (types) in the relation model, but be aware
> that subclassing is NOT subtyping.
>
I disagree. Classes that are reference types map to relation schemata, not relations, and definitely not domains. Domains were originally supposed to be disjoint sets of constant symbols, but instances of a reference type can appear different at different times, so they are definitely not constants; therefore, so long as there can be reference types, not all types are domains. Classes that are value types, on the other hand, can map loosely to domains, since each instance is the exact same value wherever and whenever it appears. I say loosely because whenever a value type is defined with more than one attribute, it is closer to being a relation schema for which there is and can only ever be exactly one instance than being a domain, and that instance could be referenced directly in relational expressions.
Non-simple domains, though convenient, perhaps, introduce complexity that is rarely, if at all, required. Usually, the same information can be recorded using simple domains, thereby reducing the complexity of the queries used to retrieve information, and I'm a great believer in the keep-it-simple-stupid adage. Moreover, non-simple domains do not completely eliminate the need for either nested relations or the introduction of surrogates. A relation that has a relation valued or a tuple valued attribute is not the same thing as a nested relation, because each non-simple component of a tuple in a nested relation can "mean" different things at different times, but each element of the domain for a relation valued or tuple valued attribute can only "mean" one thing for all time. As a consequence, flattening out a nested relation schema may demand the introduction of surrogates. Received on Wed Jun 17 2009 - 17:34:55 CEST