Re: choices regarding where to place code - in the database or middletier

From: Adam Jenkins (adam_at_remove.thejenkins.me.org)
Date: 01/29/04 

Date: Thu, 29 Jan 2004 16:29:22 -0500

Daniel Morgan wrote:
> We are going to have to end this one with a total disagreement. Having
> spent more than 33 years in IT and more than 15 of them with relational
> databases I have yet to ever see an example of:
>
> "Complete DBMS *dependence* means utilizing (all) those DBMS-vendor
> specific functions that optimize or implement security, performance, and
> scalability (and other stuff)"
>
> and
>
> "Complete DBMS independence means that a system is not bound to a given
> DBMS, because it uses only the functionality offered by the DBMS that is
> accessible via DBMS-neutral syntax"
>
> What you suggest is a logical impossibility.

Perhaps your having spent 33 years in IT prevents you from actually
considering what someone else writes on the subject. Joe isn't actually
advocating either "complete DBMS dependance" or "complete DBMS
independance", as you seem to think, he's just defining the two
extremes. Then he goes on to explain some of the pros and cons of
different compromises between the two extremes. I don't see why you
keep bringing up this straw man of complete DBMS independance and
resulting terrible performance; noone in this thread is advocating that.

As I understand your argument, you're saying that since it's not
possible to write *completely* DBMS independant code without losing a
lot of performance and robustness offered by proprietary features, the
whole idea of DBMS independance is nonsense. A more reasonable approach
is to have DBMS independance as an ideal, but to recognize that gains in
performance and robustness can be had by using some proprietary and/or
non-universally supported DBMS features. So you take into account the
advantages of using a certain non-standard feature, and weigh it against
the extra cost of supporting it on the different DBMSes that you want to
support. Then you wrap the non-portable functionality that you decide
to use in an integration layer which needs to be reimplemented for each
DBMS. This is similar to the approach used for graphics APIs,
filesystems, network protocols, etc.

Adam

Relevant Pages

  • Re: choices regarding where to place code - in the database or middletier
    ... >> DBMS, because it uses only the functionality offered by the DBMS that is ... > whole idea of DBMS independance is nonsense. ... > non-universally supported DBMS features. ... Then you wrap the non-portable functionality that you decide ...
    (comp.lang.java.databases)
  • Re: choices regarding where to place code - in the database or middletier
    ... >> DBMS, because it uses only the functionality offered by the DBMS that is ... > whole idea of DBMS independance is nonsense. ... > non-universally supported DBMS features. ... Then you wrap the non-portable functionality that you decide ...
    (comp.lang.java.programmer)
  • Re: choices regarding where to place code - in the database or middletier
    ... > DBMS, because it uses only the functionality offered by the DBMS that is ... whole idea of DBMS independance is nonsense. ... non-universally supported DBMS features. ... the extra cost of supporting it on the different DBMSes that you want to ...
    (comp.lang.java.programmer)
  • Re: Conceptual, Logical, and Physical views of data
    ... Frank Hamersley wrote: ... >>> Tables and indexes port very readily from one SQL DBMS to another. ... >>> features are generic. ... >> the relational model now that the relational model seems to have ...
    (comp.databases.theory)
  • Re: Object Oriented Concurrency
    ... the relational model is orthogonal to concurrency features. ... happens to be tailored expressly to the RAD CRUD/USER realm. ... since the only thing a DBMS do is to manage data. ...
    (comp.object)