Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

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 <marshall.spight_at_gmail.com>
Date: 2 Jun 2006 01:44:10 -0700
Message-ID: <1149237850.882603.7530@f6g2000cwb.googlegroups.com>


Robert Martin wrote:
> On 2006-05-31 09:45:00 -0500, "Marshall" <marshall.spight_at_gmail.com> said:
>
> > That you completely fail to mention the *primary* uses
> > of a DBMS is telling. Structure, integrity, and manipulation
> > are the central strengths of a DBMS. The pride of
> > application developers (or simply their lack of education)
> > makes them want to reserve these functions for their
> > application code, because that's the only hammer they
> > know how to swing well. But application code is an
> > inferior tool for these.
>
> Dear Marshall,
>
> The soft insinuation that I am ignorant, is really just an ad-hominem
> argument. The gentle implication that I am part of an arrogant and
> ignorant group is also an ad-hominem. I encourage you to avoid such
> arguments since you are quite completely ignorant of my knowledge of
> the subject.

"ad hominem": You use that word a lot; I do not think it means what you think it means.

I have seen no occurances of the ad-hominem logical fallacy in this thread. Bob has said a few times something along the lines of, you said this, and this, and this, and it was all tripe, therefore I say what you write is tripe. This is not ad-hominem. Generalizing from what someone says to qualities about that person is not a logical fallacy. Generalizing from qualities about a person to qualities about a statement of theirs is.

My response to what you write about the correct way to write applications that manage data is that it is fundamentally incorrect, and misunderstands the proper role and use of a dbms. Now, it may be the case that you in fact don't believe what you're writing and really *do* know those things, but decline to do so for whatever reason. However I'm going to go out on a limb and claim that you don't know, or misunderstand.

I do not then conclude that you are ignorant about everything, and in fact I am willing to grant that you probably know a great deal about application development and OOP. However, when you then move out of that arena and in to the field of data management, and expound harmful and regressive ideas there, I am moved to offer up my version of Huxley's rebuke to bishop Wilberforce. If the ladies in the gallery faint, so be it!

[moved paragraph]

> I'm an old hand at many different languages and programming schemes.
> Along with all the standard application languages, I've studied and
> used languages like Prolog, Forth, Snobol, etc, etc, etc. I drew my
> first ER diagram over 20 years ago, when I already had 15 years of
> exeperience behind me, and have since used many different RDBs, in many
> different environments. I have designed reactive systems driven by
> triggers, and I have designed imperative systems driven by top down
> functions. I have worked in MIS environments and embedded real-time
> environments. I have worked on shrink-wrapped software, and
> mathematical modeling software.
>
> In short, if my way of viewing the world is "stunting" it is not
> because I haven't been learning as much as I can about as much of this
> industry as I can for the last 35 years.
>
> Oh and by the way, that last paragraph was also a subtle ad-hominem
> argument about what "it appears" my opinions might be and how they
> might be stunting.

I am not sure why you keep bringing up your background; I have already stipulated that your CV is excellent. Mine is comparable. I could also note that, knowing what I do about bell curves, that I am probably taller than you, and can probably leg press more. Neither that, nor your experience level, is relevant to the discussion of how to manage data, and to suggest otherwise *is* an ad-hominem logical fallacy.

> SO.......

> In the midst of the ad-hominems I think you made a good point. I did,
> in fact, underlay the role of the DBMS. I don't think you followed
> through on that point though. In what way does the importance of the
> DBMS impact on my assertion that the application design should not know
> about the details of the DBMS. Do the attributes of data integrity and
> manipulation mean that the application code should strongly couple
> itself to the details of the DBMS?

and

> Let's see if we can drive this back to substance. Instead of telling
> me all the things that are wrong with my upbrining, tell me what's
> wrong with my assertion that application design should be decoupled
> from database design.

Very good.

I am going to narrow the terminology down, because what you ask depends on the definition of the rather loose terms "details of the DBMS" and "database design" and "decoupling."

If you are talking about things like what kind of indexing technique does the dbms uses, or the layout in memory of the tables, then of course the application should be decoupled from these things, and it is by default. (In fact, I'm not sure how you *could* couple them if you wanted to.) I do not expect that is the sort of thing you're talking about.

I think what you mean by "database design" is specifically the logical schema of the database: the tables and their attributes.

Should the application be decoupled from these? No, it should not, and in fact it cannot. The application necessarily has to know what logical data structures are in use, and it has to know it pretty much everywhere. The schema is immanent in the application; if it wasn't, we could end up with some frankensteinian chimera that thought it was a word processor in one place, an accounting package in another, and a device driver in a third.

Consider: what does it mean to decouple two modules? It means to reduce unnecessary dependencies between them. It does not mean to remove all dependencies. If they had *nothing* in common they could not work together at all.

What *do* they have in common? What *must* they have in common? An agreed-upon interface.

So: what is the agreed-upon interface between the dbms and the application that uses the database? The schema.

We also have the issue of a data-access layer. This might be a layer that invokes jdbc directly, for example. Might we want to enmodularize this code? Okay, that's not really a word, but might we want to confine the jdbc to a single module or group of modules? Sure. And of course this module must have an interface. What shall it look like?

If it is something that could easily be reimplemented in terms of a flat file, or XML-DOM, then you've blown it. You've castrated the dbms, and now you run into the full force of Spight's Law, because you haven't done anything to address the problems of data management. You can't make issues of integrity enforcement and data manipulation, transaction processing and concurrent access, etc. go away just because you wield the Mighty Sword of Decoupling. All that buys you is better maintainability of your code; it doesn't actually implement any features. Now you have to go and implement the half of a database that you would have used.

If, on the other hand, the interface to this layer is very high level, application-specific stuff, then maybe you did a good job.

Marshall Received on Fri Jun 02 2006 - 03:44:10 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US