Re: The wisdom of the object mentors (Was: Searching OO Associations with RDBMS Persistence Models)

From: Robert Martin <>
Date: Tue, 13 Jun 2006 13:06:00 +0200
Message-ID: <2006061313060037709-unclebob_at_objectmentorcom>

On 2006-06-02 17:55:35 +0200, "erk" <> said:

> Robert Martin wrote:

>> However, the data cannot remain in the DBMS for its entire lifetime.
>> The RNA has to leave the nucleus and get out into the cytolasm to do
>> it's work.  And out there in the cytoplasm the integrity of the data is
>> no longer the responsibility of the DBMS.

> Both the genetic and the distribution network analogies are so bad as
> to be useless. Data and information do not "move" in any meaningful way
> (just as systems are not "constructed" in the same sense as either a
> car or a building).

You and I have a very different view of how software systems are built.  In my world the data moves from magnetic domains on the disk to electric fields in MOSFETS. From that point the data moves from one set of MOSFETS to another, but changes form many times, until it gets to the form of an array of tuples that corresponds to some programming language interface. From that point it moves yet again to yet other MOSFETS under the control of the application and takes forms that are more convenieht for the application programmer to maniuplate. In the midst of all this the data may move from MOSFETS to voltage potentials along a wire, or frequency phase shifts along radio waves.

To paraphrase Gallileo (appochraphal) "And yet the data moves."

This is not a frivolous argument. In a logical sense the data moves around in the application, completely cut off from the database and it's integrity rules, until such time that the application hands the data back to the DBMS.
During that time the application has control.

> The various DBMSs in a federated or distributed
> architecture all have responsibility for the data integrity; if an
> application "decides" to create bad "data", it's not data and will be
> unacceptable when saved.

This is certainly true. However, the application has the responsibility NOT to create bad data. I agree that the database should reject bad data; but that's not really the solution. The solution is for the application to correctly manage the data until such time as it returns it to the control of the DBMS.

>> So applications have an equal responsibility to maintain the integrity
>> and security of the data while they control that data.


> They don't control the data. It's not handed off like a hot potato.

I disagree. For periods of time the application has absolute control of the data.

> Is it useful to view the DBMS as
> something that should be replaceable regardless of the concepts in
> which it "renders" business rules? If so, you may as well just
> serialize to a file (see Prevalyer for a degenerate example, though not
> as degenerate as some) and give up.

Why? If I can use a good RDBMS to manage my data; and can yet transform that data into a form that is convenient for my application, why shouldn't I do that?

> At some point the application has to know what it's getting from a data
> source.

Certainly. And it must also transform it into a structure it can conveniently use.

> and relations are a much more expressive gift than most other
> alternatives.

Certainly, but they are not always the most convenient form. And even if they were always the most convenient form, the structure of the relationships is not always the most convenient structure.

Example: I have a table of readings, in which seq_num is a unique key.


I want to tranform this into a table of weekly averages of daily maximums, in which week_number and name are keys.


And then I want to fire up Excel and use the COM interface to draw a line graph of the weekly averages of each 'name' for the last six months.

Robert C. Martin (Uncle Bob)  | email:
Object Mentor Inc.            | blog:
The Agile Transition Experts  | web:
800-338-6716                  |
Received on Tue Jun 13 2006 - 13:06:00 CEST

Original text of this message