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

From: Marshall <>
Date: 2 Jun 2006 10:29:02 -0700
Message-ID: <>

phlip wrote:
> Marshall wrote:
> >> Team A, however, can sack its DBA any time they feel like, and can easily
> >> replace the DB-facing modules with some other system.
> >
> > False! You might switch Oracle and DB2, but you're not going
> > to "easily" replace Postgres with read/write/seek unless you've
> > completely failed to understand the value and proper use of
> > a DBMS, and treated it as no better than a record store.
> Here's James Kanze, many winters ago:
> ----8<-----------------------------
> My point is really fairly simple:
> 1. Standard libraries are, by their nature, general. This implies a
> "wide" interface. And it has a sometimes significant price in run-time.
> 2. At the application (design) level, you don't need the wide interface,
> and a class customized to the required "narrow" interface can probably
> be far more efficient.
> 3. If the wide interface is present, some one is going to use it. Which
> means that you cannot later switch to a narrow interface.
> A simple example would be a text editor. A priori, the standard string
> class provides all of the functionality needed. On the other hand, the
> probability that the implementation is optimized precisely for your
> editor is pretty slim. If you design your editor using the standard
> string class as the text buffer, it is going to be next to impossible to
> optimize it later. A better solution would be to design a text buffer
> class, with exactly the needed functionality (and no more), and use the
> standard string to implement it.
> --James Kanze
> ----8<-----------------------------
> Now work his example, replacing editor with application, and string class
> for database. Narrow any wide interface down to what your application
> needs, then program to that interface.

Well, it completely breaks down when you do that, doesn't it? Both in the textual substitution, and in actual practice.

I also note that you have (again) used an example in which the dbms is placed in the role of a simple storage mechanism, the "text buffer." A dbms is not a storage mechanism. Until you understand this, you will not be in a position to take advantage of what a dbms offers.

Marshall Received on Fri Jun 02 2006 - 19:29:02 CEST

Original text of this message