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 10:29:02 -0700
Message-ID: <1149269342.445361.146660_at_i39g2000cwa.googlegroups.com>


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