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: topmind <topmind_at_technologist.com>
Date: 17 Jun 2006 17:27:50 -0700
Message-ID: <1150590470.655706.174960@f6g2000cwb.googlegroups.com>


Robert Martin wrote:
> On 2006-06-03 01:50:04 +0200, "topmind" <topmind_at_technologist.com> said:
>
> > I've worked with code where the SQL was "encapsulated" in a seperate
> > area. It was PAIN in the Arse.
>
> I've worked with code where the SQL was embedded throughout. That's a
> pain in the ass too. The code constantly oscilates between three
> different languages. (SQL, Tables-rows, code).

I find that if the SQL that is related to a given *task* is nearby, then it makes modifications easier than if there is a physical location separation or thick interfaces between the SQL and the app code.

>
> One system I worked on completely melted down when the DB vendor went
> out of business. There was no way to find and replace all that SQL
> (though we tried for 6 months).

A language vendor can go out of business also. Or a GUI vendor, or an OS vendor. We can't write wrappers for everything that might go out of business. Use an open-source RDBMS if that is a big fear.

There is maybe a 1-in-20 [1] chance of a DB vendor going out of business in 10 years, yet the wrappers and separation will add a coding and maintenence cost of about 30% to the code. Thus, you are spending 30% to prevent 5% (1 in 20). Not a good trade-off.

Do you buy Meteor Insurance?

[1] Most vendors that go out of business sell the product to another vendor, usually CA. It is rare for a medium or big DB vendor to disappear and take their products with them to the grave. It is better to use the sell of the product to help pay for bunkruptcy costs.

>
> There are no easy aswers. Software is hard. Encapsulating SQL has
> it's costs and it's benefits. For large systems I think the benefits
> exceed the costs because of the flexibility, and testability that it
> affords. But I agree that layers of abstraction bring their own
> difficulties.

Let's just agree that one needs to weigh the various costs and risks for each situation. "Always do X" rules are dubious. It is best to teach *all* the pro's and con's of an idea.

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

-T- Received on Sat Jun 17 2006 - 19:27:50 CDT

Original text of this message

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