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

From: x <x_at_not-exists.org>
Date: Tue, 13 Jun 2006 16:05:00 +0300
Message-ID: <e6mcus$dr4$1_at_nntp.aioe.org>


"Robert Martin" <unclebob_at_objectmentor.com> wrote in message news:2006061313060037709-unclebob_at_objectmentorcom...
> On 2006-06-02 17:55:35 +0200, "erk" <eric.kaun_at_gmail.com> 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."

In my world data gets created, copied and destroyed. Wait, the code is the one that dance around the data. :-)

> 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 DBMS is the service which has all the responsabilty for data. The application that has control is either the DBMS or some low level driver for serial communication.

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

If the data is not under the control of the DBMS, then it is not created yet.

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

The only control it has is input/output (copy).

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

If serial files and RDBMS are interchangeable for your application, then your application has no need for a RDBMS.

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

Structure ? How can one use a structure and why ?

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

Form ?

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

> |seq_num|date|name|value|

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

> |week_number|name|average_value|

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

You can point Excel to your |week_number|name|average_value| relation to draw the pretty pictures. Received on Tue Jun 13 2006 - 15:05:00 CEST

Original text of this message