Re: Mixing OO and DB
Date: Wed, 05 Mar 2008 10:58:01 -0400
Message-ID: <47ceb4fe$0$4069$9a566e8b_at_news.aliant.net>
David Cressey wrote:
> "Robert Martin" <unclebob_at_objectmentor.com> wrote in message
> news:2008030416323223810-unclebob_at_objectmentorcom...
>
>>On 2008-03-03 06:50:39 -0600, "David Cressey" <cressey73_at_verizon.net>
>
> 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