Oracle FAQ Your Portal to the Oracle Knowledge Grid

Home -> Community -> Usenet -> comp.databases.theory -> Re: The wisdom of the object mentors (Was: Searching OO Associations with RDBMS Persistence Models)

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

From: topmind <>
Date: 5 Jun 2006 21:05:25 -0700
Message-ID: <>

Robert Martin wrote:
> On 2006-05-31 12:26:23 -0500, "Marshall" <> said:
> > Robert Martin wrote:
> >> On 2006-05-30 17:54:53 -0500, "Marshall" <> said:
> >>>
> >>> There are many different contexts in which software is developed.
> >>> I will speak relative to enterprise software, which is where DBMS
> >>> software is often found. In that context, the above quoted
> >>> paragraph is pure, unadulterated garbage. It is not simply
> >>> valueless; it is actively harmful. The writer furthermore
> >>> demonstrates that he completely lacks any understanding
> >>> of what the field of data management is, or what it is for,
> >>> or why it is useful.
> >>
> >> [...]
> >> Are you saying that it is "pure unadulterated garbage" that application
> >> developers should isolate their application code from the the whims of
> >> the API designers at Oracle? Should those application designers use
> >> every little cute ORACLE trick and call? Or shoudl they stick to
> >> standard SQL as proferred by ODBMS or JDBMS, etc. Should those
> >> application developers scatter embedded SQL all through their
> >> application code? Or should they partition that application code into
> >> areas that know about the DB and areas that don't? Should they strive
> >> to make it possible to swap Oracle for MySql or not? Should they
> >> strive even to eliminate the relational flavor of the data from the
> >> guts of their algorithms, or not.
> >
> > Seven consecutive leading questions and my parser runs out
> > of memory. Uh, let's see: yes, as appropriate, ideally (assuming
> > you mean JDBC; I don't know what JDBMS is), no-of-course-
> > not-I-never-suggested-otherwise, yes, no, probably not.
> >
> > (Perhaps we could come up with a better format for dialog.)
> Heck no, that was fun! But I find your answers to be contradictory.
> You say that application developers should not isolate their code from
> the DBMS API, and yet you also say that they should not spread SQL
> throughout their code. To me those two things are synonyms.
> To me, and application should be layered such that the lowest layers
> know about the data management scheme.

But SQL is not (or does not have to be) a "low level" tool/language. It is often more compact than the equivalent imperative code to do the same thing. If anything, the app code is often the low-level stuff.

> If that scheme is relational,
> then that layer knows about SQL, and is the only layer that knows about
> SQL. Higher layers make use of the abstract services of the lower
> layers.

Too big of walls between it makes for bloated, busy-work interfaces. I want to spend my development time adding value to the a program, not being an interface custodian. Interrelationships are often what makes biz apps complex. This is because the domain has a lot of interrelationships. If you code as if the real world is all isolated parts, then it will not handle change nearly as well. Marketing is especially interweaving because marketers are always looking for new gimmicks in new relationships with new connections. With production and engineering moving overseas because of cheaper labor, marketing is having more and more influence here (for good or bad). Being nimble is growing more important than protecting against once-per-decade changes.

> Robert C. Martin (Uncle Bob) | email:

-T- Received on Mon Jun 05 2006 - 23:05:25 CDT

Original text of this message