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: Tony Andrews <andrewst_at_onetel.com>
Date: 1 Jun 2006 02:31:27 -0700
Message-ID: <1149154287.668637.302210@u72g2000cwu.googlegroups.com>


frebe73_at_gmail.com wrote:
> > Decoupling is good, if done at an appropriate level. However, given
> > your preference for swapping out DBMSs "at a whim" you clearly have no
> > choice but to use the lowest common denominator abilities of all DBMSs
> > that might be chosen, which probably amounts to some very simple
> > low-level DML and SELECT statements. Then you effectively build your
> > own pseudo-DBMS on top of this with application code. What a waste of
> > time and effort, not to mention the money you spent buying a DBMS of
> > which you refuse to use 95% of the power!
>
> This is simply not true. I have been converting a major enterprise
> application from Informix to also support Oracle and SQL Server. I
> think that we had to rewrite less than 5% of the SQL statements. In
> almost every case we were able to use the same query for all vendors
> without changing the semantics of the original query. In some severe
> cases we had to "wash" the SQL statement using simple find/replace
> functions, to fit different vendors. The conclusion was obvious:
> Continue to embedd (ANSI) SQL in the application, but make your own
> (JDBC/ODBC/ADO) driver on top of the vendor driver, to eliminate the
> remaining incompatibilites between vendors.

Fair enough. But in that case you have at least committed to using a SQL DBMS, and that it will be from one of the major players in the market. That is somewhat different from RCM's position, which is (as I understand it) that it should be trivial to unplug your SQL DBMS and replace it by something else that doesn't even use SQL. Received on Thu Jun 01 2006 - 04:31:27 CDT

Original text of this message

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