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

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 Received on Thu Jan 29 2004 - 15:29:22 CST