Re: OO vs. RDB challenge

alex99_at_medcentral.com.au
Date: 03/20/05 

Date: 20 Mar 2005 01:32:18 -0800

Costin Cozianu wrote:
> alex99@medcentral.com.au wrote:
> > Costin Cozianu wrote:
> >
> >>alex99@medcentral.com.au wrote:
> >>

(snip)

> > The challenge happens to be limited to functionality that falls
> > squarely within the reach of SQL and so it makes SQL shine.
> >
> > The logic appears to be "if SQL is so good at such a trivial
example,
> > then it must also be very good at more substantional examples".
This is
> > the problem. Technology does not scale linearly.
> >
>
> It happens like this: if for OO code is so complex to manage almost
the
> simplest of relationships ...
>

That is the problem, this reasoning assumes linear scalability but this
isn't the case.

Remember I am addressing your conclusion and not your challenge.

The challenge focuses on SQL yet somehow the conclusion is far more
general than that.

You conclude ''In particular this page debunks a pervasive
misconception ... that RelationalModel is *not as good* at
representing "relationships" as object models.''

These are general, they apply to information and software
beyond the sphere of DBs and SQL.

Now consider the internals of a more complex model, say the
internals of a wordprocessor or spreadsheet.

They have plenty of "many to many" relationships in there. Yet SQL
cannot be used for so much as one of them.

Don't say this is irrelevant (as you do below).

Had you limited your conclusion only to the sphere of the challenge
then you may have a point.

Had you concluded: "SQL provides some useful functionality
that is not easily mimicked by using OOL's and it requires
fewer lines of code to implement some features" then I
would agree with you.

However since you went on to generalize about the Object Model
then you need to deal with its strengths not just the
particular weakness you have chosen to showcase.

You wanted to use the challenge to "debunk the misconception that
the ''Relational Model is not as good at representing
"relationships" as Object Models"''

Yet when I speak of scenarios that the OM is good at you say they are
irrelevant.

Costin you cannot have it both ways. Either change your conclusion,
limit it only to the challenge or face the facts that the "RM
implementations are not as good at modeling complex relationships
as the object model" (to use words similar in style to yours).

> > I am constantly integrating diverse information sources:- from
> > databases, sockets, XML, LDAP, text files, spreadsheets, Corba, MQ,
> > EJBs, dbmfile's, web pages, email ...
> >
>
> Irrelevant.

No. I am within scope of your conclusion where you speak of modeling
relationships. The above technology models relationships and you speak
of the Object Model, which I use for the above where OOP is up to the
task SQL isn't.

> > At this level of information management clearly a database and SQL
is
> > out of scope and beyond their realm. Something more powerful is
> > required.
>
>
> Non-sense. If you want to call a Ferrari more powerful than a
> Freightliner, it will only betray your ignorance. You can't haul
> trailers with Ferrari, so anybody who claims one "better" than the
other
> is just a dumb ignorant.

Excuse me I was expecting an intelligent discussion, am I mistaken?

In your conclusion you used the phrase "not as good" I have used
the word "better" when I needed a negation, fair usage of the
English language I would have thought.

I am only addressing your conclusion in your own language.

(Or am I confusing multiple authorship on wiki's?)

> You cannot manage (i.e. conveniently supplant the features provided
by
> DBMS) data with OO constructs. And that's the bottom line. What you
do
> in the other layers is totally irrelevant.
>
> > For me, that something more powerful has been Perl and
> > Java/OOP.
> >
> > Certain OO languages are up to the task, SQL isn't.
> >
> >
>
> No, you can't street race with a Freightliner. You can haul trailers.
>
>
> > Costin WROTE: At: http://c2.com/cgi/wiki?ManyToManyChallenge >
> > BEGIN QUOTE
> >
> >>The challenge was intended to demonstrate that SQL has useful
> >>functionality that is not readily available, nor trivially
> >>implementable in OO environments.
> >
> >
> > Agreed, however, I can re-use my OO solution.
> >
>
> The non-existent one that you handwave about it.
>
> > (snip)
> >
> >
> >>In particular this page debunks a pervasive misconception
> >>(see quotes ObjectRelationalPsychologicalMismatch) that
> >>RelationalModel is not as good at representing
> >>"relationships" as object models.
> >
> >
> >>Which claim should be judged ridiculous on the face
> >>of it, but it is amusing how many "important names"
> >>in the OO camp make it.
> >
> >
> > END QUOTE
> >
> > Nothing has been debunked.
> >
>
> Posted so long ago and nobody managed to produce codce, hmmm. Call it

> what you like, I call it debunking.

You win one seat, which I have always acknowledged, then you claim
victory
in the entire election. Nice try.

> > Relational technology is good at modeling relationships but only in
> > limited contexts, beyond that you need something more powerful
(like a
> > good OOL).
> >
>
> Smacks of marketing brochure speak. Why would anyone give your
handwaved
> claim any credence ?

The credence to my claim is based on real world systems and they
address relationships and modelling as generally as you do in your
conclusion.

(Not because I can mimick certain SQL features in less lines
of OOL code as per your challenge).

Had I contrived a simplistic example that showcases only my
technology of choice and had I dismissed all else as irrelevant
then yes it would smack of brochure speak.

Thanks for the discussion,
Alex Kay

Relevant Pages

  • Re: OOP - a question about database access
    ... Object Pascal) +SQL which is a most improved version of VB. ... never a problem in my Delphi apps. ... pretty much the same as you have it in an object model driven app. ... But coding in Java provides sub-optimal performance ...
    (comp.object)
  • Re: OO vs. RDB challenge
    ... > Costin Cozianu wrote: ... > beyond the sphere of DBs and SQL. ... > However since you went on to generalize about the Object Model ... > then yes it would smack of brochure speak. ...
    (comp.object)
  • Re: OOP - a question about database access
    ... I no longer have to write any SQL. ... an object model is just a partial fragment of the whole ... > span just for the duration of a transaction. ... they also had to select a specific subset of the object model ...
    (comp.object)
  • Re: SQL-DMO equiavlent of sp_addmessage
    ... SQL-DMO is just an Automation Object Model. ... functionality already built into the database engine. ... when an application vendor wants to use MSDE, or the new SQL Server Express ... Is there any point/benefit to using it within a stored procedure, ...
    (microsoft.public.sqlserver.server)
  • Re: OO vs. RDB challenge
    ... Costin Cozianu wrote: ... I agreed that DBMSs and SQL provide useful technology (my original post ... Certain OO languages are up to the task, ... > talks and talks and talks, brags and brags and brags, but in the end ...
    (comp.object)