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: Marshall <>
Date: 4 Jun 2006 15:50:25 -0700
Message-ID: <>

Bruno Desthuilliers wrote:
> Marshall a écrit :
> > Bruno Desthuilliers wrote:
> >
> >>erk a écrit :
> >>
> >>>Robert Martin wrote:
> >>>
> >>>
> >>>>It's called decoupling. (snip) The
> >>>>idea is that you write the application program in such a way that it
> >>>>can manipulate the data in the data model without coupling it directly
> >>>>to the DBMS, or the details of the schema.
> >>>
> >>>This makes no sense to me - how do you manipulate data without knowing
> >>>the details of the schema?
> >>
> >>It's obvious that at least one part of the application must know that
> >>details ('details' as in 'detailed', not as in 'non important'). The
> >>idea is to encapsulate this knowledge in one specific part of the
> >>application instead of letting it creeps throughout the whole
> >>application. And the rational is that it should isolate the application
> >>from changes in the RDBMS (schema, vendor, whatever).
> >
> >
> > This doesn't answer the question, though:
> Yes it does.
> > how do you manipulate
> > data without knowing the details of the schema?
> It was in the very first words of my post:
> "
> >>It's obvious that at least one part of the application must know that
> >>details ('details' as in 'detailed', not as in 'non important').
> "

Every part of the application that's going to work on the application-specific data must necessarily know the structure of that data. The only exceptions would be the kinds of things like a math library or some generic utility function possibly that you wrote specifically for the app, but none of them using any application-specific data structures.

> > For an application
> > to contribute usefully to the manipulation of some data, it has
> > to know how that data is structured.
> Of course. But this doesn't mean *all* the application code needs to
> know how the data is structured *in the RDBMS* schema. *Some part(s)* of
> the application has to know about the DB schema.
> Some other parts are
> happier with an application (and language) specific representation of
> this data structure. The representation of data as exposed by the RDBMS
> schema (or XML or LDAP or whatever) is rarely (in my experience) the
> best representation for the rest of the application - unless of course
> the application's duty is to directly work on these schemas (SQLAdmin
> GUI's, XML editors etc).

I hear you saying "some parts of an application are happier using an application-specific form of the application's data." Well, what is wrong with the designer of the schema that he came up with a schema that is not well-suited for the application?

But perhaps we are talking about an enterprise situation, where a single diverse schema supports many different applications. We still assume that the schema is the one best suited to the overall needs of the system; if it is not, you should change it. Otherwise, allow the application to query the data in such a way that it gets the results back in the form it *does* like. ***SQL is the best tool for this.***

Each module in each application needs to know its appropriate subset of the database schema. You cannot operate on data that you don't the schema for, no matter how many times this idea is asserted.

> Also, having all the detailed knowledge about the RDBMS schema in one
> place (or a very few places) is very handy when one have to accomodate
> minor changes in this schema - it avoids having to browse and modify all
> the application's code. It's of course not enough to protect you from
> major changes, but then it's a totally different problem IMHO - major
> changes in the schema usually means major changes in specs, business
> rules and whatnots, so there's some redesign/rewrite to do anyway. And
> even then, the cleanest the design (read : hi cohesion, low coupling),
> the easiest the rewrite. It seems obvious (to me at least) that the less
> code you have to change, the less risks you have to introduce bugs !-)

Again: the application can't not know the structure of its data.

Let's try rephrasing what you said, so that we're talking about the object schema, instead of the database schema.

"Having all the detailed knowledge about the application's classes in one place in very handy when one has to accomodate minor changes to the classes." Can you see how and why this doesn't make any sense?

As Bob Badour said earlier, (in one of his many substantive if terse arguments in this thread), (roughly:) coherence based on structural rather than semantic issues is very weak coherence indeed. It is as if you organized your Java classes around which ones used longs vs. which ones used ints.

> I've rarely seen the case where a tuple as returned
> from a SQL query happened to be the exact desired structure for all the
> parts of the application using it.

Why did you write the query that way, then? Why didn't you write the query such that it *did* return the exact data for the parts of the application that was doing the query? If one part of the app needs one structure and another part needs another, *why* would you ever have them use the same query?!

The only reason I can think of for doing such a perverse thing would be that you had bought in to this "narrow interface" idea, and had cut yourself off from the power of the dbms, in favor of your crippled functional API, driven by the limitations of your misbegotten ORM, or your devotion to decoupling for its own sake, without paying attention to what is being decoupled from what.

Your above sentence is a great example of the problems that a number of us have been trying to point out all along. It supports my thesis perfectly.

> And even in this case, I wouldn't
> want to have to retype this exact SQL query in each part of the code
> where I need to get this representation of the data.

So make an abstraction for it. If it's the right code for several different places in the app, it's a fine candidate for a method or whatever kind of abstraction you care to make of it. You wouldn't do any differently for, say, five consecutive lines of Java that was needed in several different parts of the code.

> > The code cannot be abstracted away from
> > the question of whether it is an order entry system or a
> > geometry engine.
> True, for most of the application's own code[*]. Did I ever claimed
> otherwise ? Now I still fail to see why would imply that all the
> application code should have detailed knowledge of the RDBMS schema.

I didn't say it could. It is not the case that all the code needs to know all the schema, nor more than it is the case that all the code needs to know every class. But every bit of code that works with customers needs to know what attributes a customer has; there is no escaping it. These attributes will be present in the customers table, and present in the customer-specific application code. You *can't* get away from that.

> >>Someone here claimed that (RDBMS-based) applications should be nothing
> >>more than user-friendly substitutes to the RDBMS console. This is of
> >>course mostly false [1]. But even in this rare cases of a DB-UI
> >>pipeline, there's this "user-friendly" requirement...
> >
> > What, you can't build a user-friendly view if the model is
> > an RDBMS, but you can if it's objects?
> The model is not "an RDBMS". The RDBMS schema is one representation of
> the model. Which is totally different.

If you have a conceptual model for your application or enterprise system, you then realize this model in the logical schema for the database. The schema *is* the model. If you discover at some moment that the model has changed and the schema no longer reflects it accurately, then you need to change the schema; indeed, this is where schema changes come from.

The schema is the model; the model is the schema. What would motivate you to have them be different things?

> What I say is that just pipelining from RDBMS to UI and back is not
> enough - for the final users at least. Strange as it migh be, final
> users of my apps usually don't give a damn about the RDBMS schema - nor
> about how I designed and coded my app FWIW.

I agree that UIs can be quite sophisticated.

But I disagree that users don't care about the schema. Users *do* care about the model for the application you are designing. They care a lot about what fields a customer entity has. That's what the schema is: what entities are there, what attributes do they have, what relationships do they have among them? Users care about that.

> I deliberately choosed the words "table" and "foreign key". I'm not
> debating mathematical theory here, but talking about very practical
> application design and implementation concerns. RDBMS are an
> *implementation* of the relational theory

Yes, but your database schema is not an implementation, it is an interface. It is the interface to the logical model of your application.

> (and AFAIK not really a perfect one).

(No argument here.)

> When working on a RDBMS-based application, I'm dealing
> with a RDBMS, not doing mathematics.

Computer programming is doing applied mathematics.

Science : engineering :: math : writing software

> > I cannot make sense of this. The app must know that there exists
> > a set of orders, but knowledge of the orders table, which is nothing
> > more than a set of orders,
> An 'orders' table in a RDBMS is not 'a set of orders' - it's how the set
> of orders is represented by the RDBMS. Which is totally different (from
> an implementation POV).

Completely incorrect. The orders table in the database is exactly and completely a set of orders, and no other thing.

> How this set of orders is represented by the
> RDBMS is definitively not something the UI code has to know IMHO (which
> itself comes from experience).

Again, incorrect. The UI has to be written such that it knows what fields the orders table contains. It cannot escape having this knowedge. The schema for the orders table is nothing but exactly that information that order-related code in the application needs to know.

Lots of application programmers understand the difference between a Java interface, which is completely free of implementation details, and a Java class that implements that interface. The Java interface is a logical model.

What many of these application programmers fail to understand is that a SQL schema is also a logical interface, and in fact a completely programmable one, unlike the completely static Java interface.

While you might need to wrap a Java interface with another Java interface, you wouldn't need to if you could just tell the first inteface to please act like the interface you wanted instead, like you can with a SQL dbms.

> ... The UI code's responsability is to display the user a
> representation of the data (including what's needed to take action on
> these data) that matches the user's view of the data for a given job.

And the dbms's job is to supply a representation of the data that matches the UI code's query for the data it needs. Their roles match up perfectly.

Introducing any layers between them is introducing friction.

> BTW, no need to try and convince me of the benefits of the relational
> theory - I'm already sold[*] !-) But there's a gap between the
> relational theory, SQL databases, and application programming languages.


> Now I'm still dreaming of a *sane* bridge between these parts - but I
> certainly don't have the required knowledge to solve this.

I believe that making existing application languages able to support the high level of abstraction found in the relational model will be necessary. For example, once you have declarative integrity constraints, you don't need encapsulation. For that to happen, though, you need a language based on a solid formalism, such as set theory/predicate logic.

> NB : Ho, yes, one last point : as you can guess from my name (and
> various syntaxic, grammatical or spelling errors), I'm not a native
> english speaker. So please keep in mind that what I write here may not
> always accurately express what I'm really trying to say.

You English is excellent, to the point that I usually have no consciousness of your not being a native speaker. Your ability to communicate your ideas is also quite effective. I just disagree ....

Marshall Received on Sun Jun 04 2006 - 17:50:25 CDT

Original text of this message