Re: Object-oriented thinking in SQL context?

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

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:

How do OO class concepts map to SQL table concepts?

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.

I ask the same question: How is SQL different and similar to what I already know.

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. Some of the posts I have seen in other threads in this forum suggest to me that the database community sees the apparent discrepancy in terminology between it and the rest of the world, is the rest of the world's problem.

If these impressions are indeed correct, please state it unequivocally, and I will stop wasting my and everybody else's time.

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

That's a problem with the database community, not the question.

Dr. C. Received on Tue Jun 09 2009 - 15:56:05 CEST