Re: Object-oriented thinking in SQL context?

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.

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

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

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

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

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

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

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.

> That's a problem with the database community, not the
> question.
Maybe the problem lies elsewhere...but since you are so convinced then I wish you have a good luck in your endeavours.

> Dr. C.
Received on Tue Jun 09 2009 - 16:29:04 CEST