Re: Mixing OO and DB

From: Bob Badour <>
Date: Wed, 05 Mar 2008 10:58:01 -0400
Message-ID: <47ceb4fe$0$4069$>

David Cressey wrote:
> "Robert Martin" <> wrote in message
> news:2008030416323223810-unclebob_at_objectmentorcom...

>>On 2008-03-03 06:50:39 -0600, "David Cressey" <>

> said:
>>>In my original perspective,  the single thing that ties together all the
>>>applications and all the databases that collaborate by sharing data is

> just
>>>one thing:  data.  If you understand the data,  and you understand the
>>>(observable) behavior of each of the applications and each of the

> databases,
>>>you can understand the system.  Otherwise,  you can't understand the

> system.
>>First of all, I'd like to thank you for that.  It was very well done,
>>and I found it educational.
>>Niklaus Wirth once wrote a book entitled: "Algorithms + Data Structures
>>= Programs".  I think that title should be taken seriously.

> Agreed.
>>I completely agree that you cannot understand a system unless you
>>intimately understand the data.  By the same token you cannot
>>understand a system unless you intimately understand what it does with
>>that data.  Data and behavior are perspectives, but not ends in and of
>>themselves.  You can look at a system from a data point of view, but
>>you can't escape the need to understand the required behaviors of that
>>system.  By the same token you can look at a system from a behavior
>>point of view, but you can't escape the need to understand the data.

> It depends. For centuries, humanity had systems that captured data, and
> made it available to other people. Systems that automatically transform
> data are a more recent invention. Even a tool like Napier's bones or like
> the abacus doesn't transform data automatically. It enables an operator to
> transform data more expeditiously. Programmable systems are a more recent
> phenomenon.
> All this leads me to claim that data is more fundamental than behavior. Not
> more valid. Just more fundamental. You can have systems that have data but
> no behavior. You can't have systems that have behavior but no data. At
> least not the kind of systems you and I are discussing.
>>It seems to me that some folks in these forums think that one point of
>>view is more valid than the other.  That's absurd.  There is no truly
>>favored point of view.  Both need to be taken very seriously.

> As I said in my earlier comment, it's a matter of perspective.
>>However, when writing application code is often advantageous to take a
>>behavioral perspective.  By the same token, when designing queries and
>>modeling enterprises it helps to take a data point of view.

> I have a minor quibble with this. It isn't, AFAIK, the beginning of a major
> battle.
> The design of queries is not where the data centric view acquires its power
> and its relevance, IMO. It's in the design of data for later query. The
> design of a query has a lot in common with the writing of application code.
> One can even say that the query, once written, represents something like
> code. I hesitate to call a query an algorithm, because algorithm suggests
> "how" rather than "what". Bob Badour has already stated very concisely why
> "what" is better than "how" in most situations. If you filter his comments,
> you probably missed this. Too bad. He said it well.

Chris Date said it even better in his book: _What Not How_

> In terms of practical experience, a lot of times when programmers who were
> SQL newbies approached me with requests for help designing queries, part of
> the problem turned out to be rooted in an unfortunate (or at least quirky)
> design of the tables themselves, and not a deficiency in the programmer's
> grasp of SQL. The whole question of helping newbies with SQL is worth
> another discussion. That discussion might hinge of some aspects of the DB
> versus OO way of looking at the world.
> The design of tables calls for a very intimate understanding of the data
> itself, together with a good grounding of knowledge about data itself. The
> lack of grounding regarding data is, IMO, one of the principal causes of
> bad database design over the last 15 years. I am sure, without any direct
> knowledge, the world of OOP is full of bad OO design examples over the same
> time frame.

It's even worse in the OO world because no formal measurement of quality exists. While normalization is only a small part of design, it is the only part where we have truly objective criteria.

> But I digress. If data is more fundamental than behavior, as I claim,
> then data design has to be treated as more consequential than behavior
> design. I'm not sure exactly what I mean by "consequential", but "harder
> to reverse" is part of what I'm driving at. Data design includes database
> design, but is by no means limited to database design. The message systems
> by which a bunch of objects interact needs to be designed. I'm calling
> those messages data (even though I've seen some opposite comments from c.o.
> regulars). And therefore the design of a message system for an OO system is
> data design, if you accept my nomenclature.
> The best integration of the OO point of view with the data centric point of
> view I've seen is "Object Oriented Analysis" by Coad and Yourden. A lot of
> the squabbles between c.d.t. and c.o. would be resolved if people could just
> read that book or some suitable successor to it.

I read that years ago. A lot of squabbles between c.d.t and c.o would be resolved if the self-aggrandizing ignorants over on c.o would eductate themselves. Received on Wed Mar 05 2008 - 15:58:01 CET

Original text of this message