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

Robert Martin wrote:
> On 2006-05-30 07:51:15 -0500, "CMCC" <c_jackal_at_hotmail.com> said:
>
> > Robert Martin wrote:
> >> No, a DBMS is a bucket of bits with some low level rules to manage
> >> those bits. An OO application provides the beavior that the customer
> >> wants to see. We can completely eliminate the DBMS and replace it with
> >> another of an entirely different form (non Relational for example) and
> >> still have all the business behavior we need.
> >> The people who sell databases have sold you, and the industry, a
> >> misconception: that the database is the heart of the system. This is
> >> flawed. The heart of the system is the application code. The database
> >> is a detail to be decided at the last possible moment and kept in a
> >> position so flexible that it can be swapped out for another at a whim.
> >
> > No, a OO application is a bucket of bits with some low level rules to
> > manage
> > those bits. An DBMS provides the beavior that the customer
> > wants to see. We can completely eliminate the OO application and
> > replace it with
> > another of an entirely different form (non OO for example) and
> > still have all the business behavior we need.
> >
> > The people who sell OO applications have sold you, and the industry, a
> > misconception: that the OO application is the heart of the system.
> > This is
> > flawed. The heart of the system is the DBMS. The OO application
> > is a detail to be decided at the last possible moment and kept in a
> > position so flexible that it can be swapped out for another at a whim.
>
> Let this be a lesson to all you cowards who resort to ad-hominem
> attacks and name calling. THIS post is a very good rebut to mine. He
> actually used his BRAIN to invert my argument and throw it back in my
> face. And he did it without calling me a fool, or an idiot, or a
> trickster.
>
> Carlos, I have to agree with everything you said.

I didn't said much, did I?
But... are you saying you agree with everything I said *and* everything you said? Both visions are way apart.
Maybe this is a circle and very apart visions meet each other at one point?

 From the
> data=modeler's point of view, the application is just a pile of
> behaiors.

  Applications will come and application will go, but the data
> structure will remain. It may change. It may grow. But it will
> always be there!

Hold on to this one!

>
> And this brings us to the real issue at hand. Each side views the
> other as a bucket of bits! Is this an error? Is this a flaw? No!
> This is good software design! It is the role of software design to
> abstract away the details. From the point of view of the application,
> the database is a detail. From the point of view of the data model the
> applications are details. And that's the way it SHOULD be.

But above you say applications come and go.. and the data structure will remain. It seems to me the data structure is quite a huge detail and
applications little details then. I mean.. from the point of view of the
whole system and with lots of time.....

>
> Application developers get into trouble when they DONT treat the
> database as a detail.
>

It's a huge detail because the DBMS is forcing on them the structure of the data and the rules by which this data may or may not be changed within that structure. And by rules I mean *all* the rules to which the

data, even derived data known to the DBMS, has to comply (constraints, business , static, dynamic, ... doesn't matter what they are called)
The DBMS has to! With all this applications coming and going someone has to take charge.

>
> Data modelers get into trouble when the DONT treat the applications as details.

They (with the DBMS) have to provide an interface and deliver what that interface
is promising. And secure the data. Requests from outside (god may know how many applications are trying to 'store things' each with its own view
of what the database should be doing for them) may change the database *only*
to a new valid state (reachable through a valid state transition).

Maybe this is an acceptable analogy (not meant to be precise!): The whole system is composed of the following: ( MVC design pattern) Database (Model) Keeps its own state valid (the controller helps) no matter what the

           applications (views) are asking. DBMS (Controller) Provides an interface (SQL?) and controls communications and a lot

        of other things (*checking rules*, transactions, concurrency.. whatever).
Applications (View) communicates about facts with users and from/to the database
through the controller.

Regards,
Carlos Received on Wed May 31 2006 - 23:15:22 CEST