Re: Object-oriented thinking in SQL context?

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 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.

> > 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?

> > 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?

> > 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?

> > 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' ?

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.

Dr. C. Received on Tue Jun 09 2009 - 17:16:13 CEST