Re: Object-oriented thinking in SQL context?
Date: Tue, 09 Jun 2009 13:04:47 -0300
> 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:
>>>>>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
>>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
> > 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
> > 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
> Ah, at last we are getting somewhere. Any pointers to books?
Google "third manifesto"
> Any quick'n dirty synopses of the arguments?
>>>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.
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
> > 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