Re: The wisdom of the object mentors (Was: Searching OO Associations with RDBMS Persistence Models)

Thanks for the guidance...I will keep in mind your advice to give more targetted questions...The subject would be to find out how and what OO mechanisms (nice definition) can contribute to build better implementations of relational requirements throughout the system life cycle...

Questions I would like to discuss are of the following type:

> What are the available OO languages that can do a better job than SQL into handling data definition and manipulation...Java?
> What are the limitations of these languages to do what's above? What's currently missing in OO (Is object "persistence" a desperate attempt at establishing representations of R Tables)

My point is to help establish a practical list of feature (some kind of Bill of Material) of important requirements OO languages should meet to be potential candidates to better allow relational implementation. I do believe this kind of debate can be more useful that raw opposition between programmers and relational advocates. As you stated, OO can in no case be put on the same standpoint than relational model as they are of totally different nature...In a schematic manner, it seems OO is more about implementation than abstraction only a model can bring. It also seems to me OO mechanisms could do as well as current SQL (at least its current form) into implementing better DBMS... Question is how?

Thank you for helping into that direction... Here is the thread

http://groups.google.com/group/comp.databases.theory/browse_thread/thread/54e82593b205a2a8

Bob Badour wrote:
> Cimode wrote:
>
> > Hello,
> >
> > I noticed a recurring commercial argumentation about creating
> > *behavior* into components (named classes). This caracteristics is
> > often presented as being a differentiation of relational model where no
> > such thing really exists (and in fact is not necessary). In a word, In
> > OO approach (for whatever it may rely on), one of the main limitation
> > of relational model would be not to allow its elementary components to
> > emulate elementary predefined processes (transformations for instance).
> >
> >
> > I have the impression, there is a concept, unbearable to some
> > programmers that data management systems can not be anything else than
> > a mechanized set of tool that could help structuring data for human
> > interpretation. On that standpoint, relational model components
> > reflect an approximation of *meaning* concept as being a contextualized
> > and specific combination of constraints, business rules to make
> > predefined inferences about that data for preparing interpretation.
> > Processes are defined only according to specifically defined
> > inferences. On the other side, OO approach seems to advocate that some
> > level of elementary process autonomy will end up creating *some* form
> > of intelligence thanks to some cumulative effect. On such perspective,
> > I start suspecting all debate stating behavior lacking in the
> > relational model is an empty unfounded attempt of some IT professional
> > to project their scifi fantasies about what system could do and what
> > they can actually do in a realistic manner.
> >
> > On the other side, some OO advocates state that OO approach brings some
> > features that would seem to better implementations of subtype and
> > supertypes features through inheritance as well as a better in memory
> > physical handling of non primitive types than what we are accustomed to
> > with traditional SQL implementations.
> >
> > I am curious about your opinion about this matter as this is a new
> > board for me. (Sorry if you have noticed some english errors as it is
> > not my native language) so bear with me please.
>
> Cimode, the above seems like a rather broad overview of OO and the RM. I
> am not sure what you are seeking an opinion about. As a general rule
> online, the more specific the question the better then answers.
>
> The relational model is symbolic logic.
>
> OO is a low-level mechanism for creating large unpredictable state
> machines out of smaller predictable state machines. OO is all about
> managing variables.
>
> After OO was created, folks noted that it has some utility for
> abstraction and reuse. However, the RM is a much better model for
> abstraction, has a more sound foundation, and provides more effective reuse.
Received on Thu Jun 01 2006 - 11:48:03 CEST