Re: Object-oriented thinking in SQL context?

From: Bob Badour <bbadour_at_pei.sympatico.ca>
Date: Tue, 09 Jun 2009 13:04:47 -0300
Message-ID: <4a2e8822$0$23763$9a566e8b_at_news.aliant.net>


dr.coffee1_at_gmail.com wrote:

> On 9 Jun, 16:29, cim..._at_hotmail.com wrote:
> 

>>On 9 juin, 15:56, dr.coff..._at_gmail.com wrote:
>>
>>>On 9 Jun, 14:49, cim..._at_hotmail.com wrote:
>>
>>>>Snipped
>>
>>>>>The database community can handle this in a couple of ways:
>>
>>>>>1) Close in on yourself and mock people who do not have the
>>>>> insights you have.
>>>>>2) Recognize the problem and help sort out the misunderstandings
>>>>> and snags.
>>>>>Over the past couple of days I have got a clear impression about
>>>>>what approach seems to be preferred by the regulars here.
>>
>>>>Let me get this straight. You need help from the database community
>>>>for a design exercice but you need that help to be done according to
>>>>the principles you believe are universal (whatever these may be).
>>
>>>As for my starting point, I have made the observation that
>>>object orentated designs and methodologies are more or less
>>>universally useful in programming and general system analysis.
>>>Check the textbooks in just about any such activity, be it
>>>programming, buisness modelling, XML or UML. My personal
>>>experience coincides with this impression - OO is a very
>>>useful tool.
>>
>>I am not aware of any precisely and consensually OO defined concept.
>>I have asked hundreds of OO programmers in the past about a definition
>>about what an object and each of them came with a totally different
>>definition.
> 
> You are a database desinger, right? Do you ever use the
> 'entity-relation' method when you design a database?
> If so, what is an 'entity'?

As Dr. Codd so succinctly pointed out over 2 decades ago: An entity is a relation and a relationship is a relation.

>>>I have also made the observation that object oriented
>>>*terminology* is absent from the database texts I have
>>>available. I don't recognize the concepts I am familiar
>>>with in what I read about databases. I'm not saying they
>>>are absent; I'm saying they have taken a different guise.
>>
>>The fact that you don't recognize in database texts what you are
>>accustomed to simply means that you do not have a proper background in
>>database technology. By educating yourself, you would be in a
>>position to relate more easily what you already know. That is just an
>>advice.

> 
> Right. As I said previously, I was naive when I hoped for
> help when asking the more experienced.

We gave you help. OO concepts--for the most part--are not only not useful but counter-productive. They impede communication and mask a lack thereof.

>>>How do OO class concepts map to SQL table concepts?
>>
>>Simple, they hardly do. OO concepts are way too imprecise to be
>>mapped to the rigor of database theory.
>>
>>I suggest you take a look to some of Date's books where he treated
>>that subject.
>
> Ah, at last we are getting somewhere. Any pointers to books?

Google "third manifesto"

> Any quick'n dirty synopses of the arguments?

No.

>>>It's a trivial question that I have found no clear answer
>>>for, neither in my books or here. Check out a textbook
>>>on C++, 'You Can Program in C++' by Glassborow. It is
>>>intended for programmers who know some other programming
>>>language and want to learn C++. The author includes a
>>>number of sections on how C++ is similar and different
>>>to a number of languages, like C, Java, Fortran, etc.
>>>While the section doesn't tell anything a programmer who
>>>knows both C++ and, say, Java knows, it summarizes it
>>>up front so that the newbie has a chance to sort out
>>>'philosophical' and practical differences. This kind
>>>of thing would be immensely helpful for somebody who
>>>just starts out.
>>
>>Or maybe you just are not ready to accept the answer as it is. set
>>oriented approaches are radically opposites of procedural approaches.

> 
> Ah, 'set oriented vs procedural approach'. The first time
> I see it. Any synopses on *how* they are different?

One approach expresses logic directly at the level of intent and the other expresses steps at the level of a physical computational model.

>>>I ask the same question: How is SQL different and similar
>>>to what I already know.
>>
>>In ways you can not tell if you do not go through a self learning
>>process of education in database concepts. If you believe this is not
>>necessary and OO concepts are sufficient to understand database theory
>>then it will be difficult to help you.

> 
> I hoped for useful answers. After two days and who-cares-
> how-many-posts, key words at last seem to trickle into
> the replies.

You must not have been listening earlier, then.

>>>This simple question has not been answered. Instead,
>>>you seem to suggest that object orientation is *not* a
>>>useful context for system analysis or design, generally
>>>or with databases.
>>
>>Well that's is a correct assertion.
>
> Huh?

A most eloquent expression of ignorance. Well said!

>>>If these impressions are indeed correct, please state
>>>it unequivocally, and I will stop wasting my and
>>>everybody else's time.
>>
>>This is the last post I am making to help you out. My time is as
>>limited as yours.
>>
>>>>Don't you think this is a hasty harsh judgment on your part ?
>>
>>>No. The database community (posters here, textbooks) seem
>>>unable to answer the one, simple general question any
>>>programmer unfamiliar with SQL will ask.
>>
>>I believe on the contrary that the question has been answered very
>>clearly by several people. The fact that you accept this response or
>>not is another matter. That is no reason for blaming an entire
>>community.

> 
> I'm blaming the community because members seem systematically
> unable to project themselves into the shoes of a newbie, and
> are thus unable to see the subject from the newbie's perspective.

Newbies--real, honest to goodness, self-aware newbies--seldom dictate the terms of an education. Received on Tue Jun 09 2009 - 18:04:47 CEST

Original text of this message