Re: OO versus RDB

erk wrote:

> H. S. Lahman wrote:
>
>>The point is that data management and problem solving are quite >>different concerns and activities.

When the hell did solving the problem of data management cease to be 'problem solving' ?!? When the hell did solving the problem of maintaining data integrity cease to be 'problem solving' ?!? When the hell did solving the problem of data manipulation cease to be 'problem solving' ?!?

Lahman is a self-aggrandizing ignorant. He wouldn't recognize a concern if it bit him on the ass.

> I don't think either one of these phrases is useful. "Problem solving"
> is part of it, but a rather small part, in my opinion. Troubleshooting
> existing systems might fall into this category. Analyzing requirements
> is a big part of our work, involving logic and notations to help
> identify gaps and inconsistencies. System design also involves logic
> and notations, of different types; specifications tie it to the
> requirements. And in coding, I'm doing more of the same: creating
> formal structures which ultimately meet the requirements. Some
> derivation, some creation, but problem solving? Not really, at least
> not for me and developers I've ever worked with.
>
> "Data management" requires data, which have specifications (expressible
> as types and constraints). Those specifications are relied on by
> multiple systems sharing the database. But other than that, the term
> "data management" is extremely fuzzy.

Actually, I don't find it fuzzy at all. Having a very wide-ranging scope and having no precise definition are very different things. Complex numbers similarly precise and wide-ranging.

> Perhaps part of my problem is the absolute vacuousness of the word
> "management."

Do you have a better word? One might argue that "data management" is not the best term for its definition, but it is now the term we have with that definition.

>>I didn't look because it is irrelevant to the discussion.  The issue is
>>not about finding an alternative to SQL for accessing an RDB.  (Though
>>clearly if one is using flat files it is not the best choice.)  It is
>>about hiding /whatever/ access mechanism one uses.

In other words, he seeks to give predicate logic all the power of a flat file and to give relations all the simplicity of a hierarchy extended to networks using pointers.

> How do you hide what type of "material" that mechanism is delivering
> to, and accepting from, its clients?

These idiots are blowing smoke out of their asses. Adding an extra level of indirection or transformation does nothing to reduce the requirement that an application know the structure of the data it uses even if it ignores the structure of the logical data model and even if it stupidly refuses to use the most appropriate and powerful tool at its disposal. That an application must know the structure of the data is as true for the structure of the data in a flat file or a non-terminating stream as it is for anything else.

>>However, outside CRUD/USER processing the solution to a particular
>>problem will almost always have a different representation of the data
>>than the DBMS so that it can manipulate the data optimally for the
>>solution in hand.

He is a self-aggrandizing ignorant. He's trying to invent distinctions that don't exist so he can make money advising people how to deal with the imaginary.

[snip]

>>The persistence mechanisms should be completely transparent
>>to the problem solution in the same sense that a particular problem
>>solution should not matter to the way data is managed on the enterprise
>>level.

Hear! Hear! Besides, predicate calculus seems rather transparent to me.

>>In a non-CRUD/USER context I have a complex problem to solve.  To do
>>that I have to manipulate data in data structures tailored to my problem
>>solution.

And if a mapping layer is required, why do that mapping with anything less powerful and elegant than the predicate calculus?

>>Those data structures are <usually> initialized by data
>>acquired from a persistent data store.  But the access of the data to do
>>that initialization is quite independent of the problem solution.

>>IOW, both the problem solution and the data access are "the code".  They
>>are separated by logical modularization and decoupling to make the
>>application easier to implement and maintain.
>>
>>I really don't know why this notion of separation of concerns is such a
>>novelty.

First, because his 'separation of concerns' bears no resemblance whatsoever to the "austere intellectual discipline" first described by Edsger W. Dijkstra. Second, because his concerns wouldn't concern any rational, informed person. Finally, his idiotic hiding of the more powerful abstraction runs directly counter to Dijkstra's original intent.

Further, the self-aggrandizing ignorant is confused among structuring, information hiding, abstraction and the separation of concerns. The intellectual discipline of separating concerns focuses the limited human intellect for tackling more difficult problems more effectively. Structuring is an intellectual discipline for keeping the difficulty of proving correctness of solutions commensurate with the difficulty of solving problems. Information hiding, like functional decomposition, is an engineering discipline for limiting the locus of effect of arbitrary design decisions.

Abstraction is "a mental tool by means of which a very finite piece of reasoning can cover a myriad cases". "The purpose of abstracting is not to be vague, but to create a new semantic level in which one can be absolutely precise."

http://www.cs.utexas.edu/users/EWD/transcriptions/EWD03xx/EWD340.html

> It's not. You're ignoring, though, the preconditions to said
> separation, and reasons for it. I don't care whether the rest of the
> application "knows" whether or not the data comes from a network or
> local DBMS, or from local memory; what's critical is WHAT it is
> getting, and operating on. Most applications (perhaps all) can be
> better written against relations, because of what the RM gives them.

The self-aggrandizing ignorant is trying to use a mechanism for limiting the scope of arbitrary design decisions to mask a fundamental need. For every application needing to manage data, data management is a fundamental need rather than an arbitrary design decision. Relations and the predicate calculus are already higher-level abstractions than what the self-aggrandizing ignorant proposes to use in their place.

>>>>Codd's relational data model as implemented in RDBs is not a data
>>>>storage paradigm?
>>>
>>>Indeed it is not.
>>
>>Wow.  I give up.  This disagreement is so profound I don't even know how
>>to begin to respond.

The self-aggrandizing ignorant is in the business of selling nonsense that he calls a 'paradigm'. For him, similarly calling useful abstractions 'paradigms' lends his nonsense an aura of respectability. That computational models are computational models and formalisms are formalisms are financially inconvenient truths for those who sell snake-oil. Received on Wed Jun 28 2006 - 22:29:21 CEST