Re: Object-oriented thinking in SQL context?

dr.coffee1_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).

That's like saying shovels are more or less universally useful in digging holes, but for some holes, a dozer, back-hoe or loader will work much better.

> Check the textbooks in just about any such activity, be it
> programming, buisness modelling, XML or UML.

99.9% of the textbooks you will find on the programming shelf in any bookstore are pure, unadulterated crap. An entire industry revolves around ignorant people repeating ignorant people. As a general rule, at any given time, the truly useful texts take up no more than 6 inches of shelf space.

> My personal
> experience coincides with this impression - OO is a very
> useful tool.

If one assumes a low-level physical computational model, it is useful. The relational model and SQL don't make that assumption.

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

Thank you for repeating what you wrote earlier. I am quite capable of reading and comprehending written english the first time, however. For your edification, I will repeat what I wrote on the topic:

"I am not sure what use you would make of OO terminology. It's all rather nebulous, overloaded and imprecise. None of it is any good for communicating much of anything."

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

The big pictures are predicate logic and set theory. I find the above paragraph ironic because when I tried to lead you to the big picture you seemed to object that I didn't give you the details you asked for.

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

Ignoring the nebulosity and overloading of the OO terms, the term "object class" maps to the concept of data type.

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

SQL is a deeply flawed approximation of predicate calculus.

>>Don't you think this is a hasty harsh judgment on your part ?

The widespread ignorance of fundamentals among the programming community is not the fault of the database community or of anyone other than the programming community. Received on Tue Jun 09 2009 - 19:45:19 CEST