Re: Relational model versus object model

From: Topmind (topmind_at_technologist.com)
Date: 02/23/04 

Date: 23 Feb 2004 09:44:58 -0800

>
> >>>* Persistence
> >>>* Query languages or query ability
> >>>* metadata repository
> >>>* Noun modeling
> >>>* Multi-user contention management and concurrency (locks,
> >>>transactions, rollbacks, etc.)
> >>>* Backup and replication of data
> >>>* Access security
> >>>* Data computation/processing (such as aggregation)
> >>>* Data rule enforcement or validation
> >>
> >>....
> >> There is nothing here that
> >>is not about simply reading or writing data. Sure, there are lots of
> >>peripheral problems related to data integrity and resource management
> >>when one gets into multi-accessor environments. And building servers to
> >>deal with those problems in nontrivial. But all these things are still
> >>just about reading and writing data from a storage device. IOW, there
> >>is no implied business problem being solved with any these things.
> >
> >
> > They are the building blocks. And, I hardly see how querying and
> > aggregation are "mere reading". Handling things like concurrency
> > is not a trivial problem to reinvent from scratch.
>
> Yes, they are building blocks -- for reading and writing data.
>
> Querying and aggregation are a basic part of persistence because the 1:*
> and *:* relationships are defined in the RDB itself. If one is going to
> read and write data aggregates, then one should employ the appropriate
> DB access mechanism for that.
>
> As far as concurrency is concerned, the DBMS is the logical place to
> address that when there are multiple readers and writers of data. A
> particular application should not have to worry about what other
> applications are reading and writing the data. OTOH, the application
> may have its own set of concurrency problems that the DBMS has no
> business knowing about.

Examples would be helpful. Note that I am a proponent of
a "local" DBMS engine for stuff that does not belong in
the "formal" or "central" DBMS.

>
> >
> > Besides, even if you consider it all trivial, I see a fair amount
> > of OO code and interfaces that waste time and code on such
> > "trivial" stuff. If we can farm off a lot of that triviality
> > to something else, we don't have to wallow in it and reinvent
> > it. We don't have to repeat set/get/find/delete etc. over and
> > over and over in our class interfaces. It is called
> > OnceAndOnlyOnce.
>
> Nice try, but I'm not going down the rabbit hole of debating OO with you.

Chicken! :-)

> >
> >>>* Multi-language and multi-application data sharing
> >>
> >>I didn't include this one because I don't know what it means. Sounds
> >>good, though.
> >
> >
> > Sharing information with multiple languages and applications
> > in a convenient, consistent way.
>
> NS,DT! That's exactly why we separate reading and writing data from
> business problem solutions. That portability is achieved by decoupling
> the DBMS from the specific business problems being solved. If the DBMS
> is decoupled from the problem solutions, it is also decoupled from the
> solution mechanisms.

Again you appear to be assuming that only persistence is being
considered.

I'll tell you what. I would like to see an OO API that does
all the above, and this includes inter-language info sharing.

Most likely satisfying this request will result in the invention
of a database of some sort (or at least an interface to one).

>
> >>>Caching allows a lot of RDBMS work to be done in RAM.
> >>
> >>That isn't the problem. It's the searches and key comparisons required
> >>when identity and relationships are tied to embedded data values.
> >>That's fine for data management or even CRUD/USER pipeline applications
> >>but one doesn't want to solve complex business problems that way.
> >
> >
> > Please define/clarify "complex business problems".
>
> Problems where the Business layer processing is large compared to either
> the Presentation (UI) or the Data layers in a conventional layered
> model. IOW, applications that are not simple USER/CRUD pipelines
> between UI and DB.

For one, you seem to assume that CRUD applications are always
simple. If they were, they would be factored into an
off-the-shelf-box. (There are RAD tools that claim to do such,
but they rarely offer or facilitate the
long-term customization that many
businesses want.) But I will agree that business applications tend to
be "link bound" as opposed to "node-bound". This means that
the hardest part of "processing" is gathering information
for many peices and sources of data. In other words, the
gathering is usually the complexity bottleneck rather than the
raw processing.

But if you have a specific example where relational tends
to choke or be complicated compared to OO, I would like to
inspect it. I am sure there are a few such cases because
nothing is good at everything. However, for the vast
majority of business applications, procedural/relational
is superior IMO. At least not objectively worse.

>
> >>>I have seen too many problems with "slotting up" phone numbers. For
> >>>example, if they suddenly decide to allow international phone numbers,
> >>>one has to undo or complicate their "slots" if the slotty approach is
> >>>taken. If you need to split them up for temporary parsing, then so be
> >>>it, but keep it a local, task-specific thing rather than a global
> >>>proclamation.
> >>
> >>That's because you are thinking in terms of enterprise DBs where there
> >>are lots of clients with potentially unlimited needs. In the OO context
> >>a class abstraction in a particular subsystem subject matter context is
> >>very myopic about its requirements. In addition, that subject matter
> >>will be abstracted using problem space invariants that maximize
> >>long-term stability _for that context_.
> >
> >
> > Context-specific is often not "long-term". Besides, one can
> > reformat stuff as needed in a given module without all the
> > syntactical overhead and "setup work" involved in OO.
> > For example, split it up and put it into an associative
> > array that a particular task needs.
>
> Actually being context-specific is crucial to large scale reuse.
> Focusing on abstracting the invariants of a specific subject matter and
> encapsulating them properly behind interfaces is an excellent way to
> provide long-term stability and isolate changes.

That is what a schema is: an interface. Data-centric interfaces
are just as useful as behavior-centric interfaces. Plus, they
make inter-language communication easier than behavior-bound
approaches.

> Maintaining a narrow
> focus facilitates recognizing invariants. That's why we have GUI
> builders, web builders, and RAD IDEs; they each abstract invariants of a
> very narrowly defined subject matter. In fact, note that SQL is an
> example of abstracting the invariants of accessing RDB persistence.

There you go again: "persistence".

But you are heading in the right direction in that databases came from
the packaging of *commonalities* of data-handling into a
language-neutral standard (more or less), IOW "abstraction". OO apps
tend to want to reinvent all that from scratch for each and every app.

That is NOT "reuse" and probably ANTI-abstraction. Relational is
clearly (to me) a superior abstraction over the
"path-and-pointer-hopping" of the 1960's database style that OO tends
to favor.

>
> H. S. Lahman

-T-

Relevant Pages