Re: Object-oriented thinking in SQL context?
Date: Tue, 9 Jun 2009 08:51:51 -0700 (PDT)
Message-ID: <35131ad1-e849-4658-bf72-99f1e134b178_at_n19g2000vba.googlegroups.com>
On 9 juin, 17:16, dr.coff..._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'?
I am a database practitionner. I did some design in the context of
SQL systems and I did not have to use any concept such the *entity
relation* method. I do not use the concept of *entity* when working
with *relations* as meant in *relational* model.
> > > 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.
You being naive is not the point I was trying to address in this
reply. You simply need to do some reading. Unfortunately that the
only way to answer your request.
> > > In my first post:
>
> > > "I have a problem with wrapping my mind into the 'right' wrinkles."
>
> > > "The [system] would be almost trivial to implement in an
> > > object-oriented context [...],
> > > but I don't see how to come up with a table-based database
> > > design."
>
> > > In my second post:
>
> > > "The problem is that I think in OO terms, like classes and
> > > inheritance."
>
> > > "So in the 'naive' problem statement I see an array of objects
> > > of classes derived from a base class [...], while I read that
> > > SQL is constrained to 'trivial' arrays. The problem is the
> > > vast philosophical distance between the two problem statements,
> > > that I am unable to bridge."
>
> > > So it would be immensely helpful if somebody could
> > > come up with a general comment about
>
> > > 1) If OO concepts can be handled at all in SQL databases.
> > > 2) If so, how it is done.
>
> > > As I'm getting older, I don't appreciate building a big
> > > picture from gazillions of details. I rather prefer to
> > > get the big picture first, and then fill in with the
> > > deatils.
> > > > All
> > > > I have seen so far are goodwill people who wanted to help you by
> > > > advising you to do some reading necessary to understand some basic
> > > > principles of database design. In a word, you ask a question and
> > > > because you don't like the answer you now imply that the *regulars*
> > > > have closed themselves and mocked you.
>
> > > I have asked the one question that just about everybody
> > > with a little bit of OO programming experience will ask
> > > when entering the world of SQL databases:
>
> > I would suggest this may not be the right place for that. You will
> > be luckier in a *database quick and dirty* forum..
>
> Pointers, please?
Maybe a good starter for you...
> > > 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?
> Any quick'n dirty synopses of the arguments?
I am afraid not...There are no easy answer to your request...
> > > 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?
Read the book provided and see the difference for yourself...
> > > 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.
>
> > > 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?
>
> 'The rest of the world is wrong, only *I* see the truth' ?
My assertion is shared by many in the database community. I also
confirm that it is perfectly possible to do database design by using
database theory only concepts. Bringing OO context does not help, on
the contrary.
> Maybe an explanation why this forum averages to about
> one post per day?
>
>
>
> > Snipped
>
> > > 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.
> That's a sign of a professional community well on its way
> to professional degeneracy.
I do not think you are having a newbie's attitude in this thread.
When a newbie *sincerely* wants to learn something, he/she does not take an attitude which consists of the following:
--> expecting the people who are *not* responsible for his/her lack of
database formal education and who do not owe him/her much to accept
his/her hurting remarks when all they do is try to help him/her
--> expecting answers with his/her terminology when well established
terminologies have been and are still used
--> ignore efforts and answers to point him/her out in the right
direction
--> declare that an entire community is degenerating.
I know of other newbie's attitudes which consist of taking a more humble approach of simply listenning to what people who have nothing against you personally may have to say. Does that sound so unreasonnable? Received on Tue Jun 09 2009 - 17:51:51 CEST