Re: choices regarding where to place code - in the database or middletier
Date: Thu, 29 Jan 2004 16:23:10 -0800
Message-ID: <1075422131.80866_at_yasure>
Adam Jenkins wrote:
> Daniel Morgan wrote:
>
[Quoted] >> 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 >> [Quoted] >> "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" >> [Quoted] >> 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
All of this fluff, and I don't mean it in a prejorative way provides no guideline. How would you make the decision as to which proprietary features such as packages and sequences you would use and which ones not to use.
Not once have I ever had a design spec. that said do a mediocre job of implementing security, scalability, and performance.
Statements like "then you wrap the non-portable functionality that you decide to use in an integration layer" are, from where I sit more fluff. How do you write a wrapper around using a sequence versus using an autonumbered column? I don't think it is technically possible.
I don't know you but strongly suspect your expertise is all front-end ... Java ... and that you really have substantial database experience.
-- Daniel Morgan http://www.outreach.washington.edu/ext/certificates/oad/oad_crs.asp http://www.outreach.washington.edu/ext/certificates/aoa/aoa_crs.asp damorgan_at_x.washington.edu (replace 'x' with a 'u' to reply)Received on Fri Jan 30 2004 - 01:23:10 CET