Re: OO vs. RDB challenge

From: Costin Cozianu (c_cozianu_at_hotmail.com)
Date: 03/20/05 

Date: Sun, 20 Mar 2005 08:25:58 -0800

alex99@medcentral.com.au wrote:
> 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
>

You're all just brochure speak. If you were expecting an intelligent
discussion, you wouldn't be trolling me.

You either have something *technical* and *concrete* and *relevant*
(claiming that SQL cannot control rocket engines is technically true,
but irrelevant to the point of being idiotic), or else this
"intelligent" discussion is over.

Relevant Pages

  • Re: OO vs. RDB challenge
    ... Costin Cozianu wrote: ... >> squarely within the reach of SQL and so it makes SQL shine. ... However since you went on to generalize about the Object Model ... Yet when I speak of scenarios that the OM is good at you say they are ...
    (comp.object)
  • 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: 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)