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

From: Daniel Morgan <damorgan_at_x.washington.edu>
Date: Sun, 01 Feb 2004 13:42:32 -0800
Message-ID: <1075671693.584495@yasure>

Joe Weinstein 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)"

>
>
> I can't understand your inability to grok this. If a product is written
> using DBMS-vendor-specific functionality in a way which makes the product
> unportable to another DBMS, it is DBMS-specific and dependent on that DBMS.

Agreed.

>> "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"

Agreed.

> A simple-minded product that connected to any JDBC-accessible DBMS, and
> sent only fresh SQL queries is an example. Not powerful but certainly
> DBMS-vendor independent.

Everytime someone disputes my point-of-view they do so with examples that don't involve transactions. My challenge to you, made as blatantly obvious as an unwashed purple rhinoceros in the middle of a living room has involved 'sequences' for a reason. Anyone can come up with a vendor-neutral select statement. I am challenging you to deal with transactions and locking.

>> What you suggest is a logical impossibility.

>
> How did I do this time? What logical failure is there in my simple examples
> above?

As I've said so many times and I am beginning to wonder if I need to SCREAM it ... you, and others that have agreed with you, have not once responded with a transaction ... only with read-only SELECT statements.

Now perhaps it is just me ... but every time I connect a relational database to a web front-end I expect it to be able to insert, update, and delete ... not just select. I expect it to be able to create new records, to lock records, to commit and rollback. Is my usage that unusual?

If you agree that a N-tier application should be able to create insert, update, and delete, transactions ... then explain to me how you can be vendor neutral and WITH THE SAME CODE handle Oracle with multi-version conurrency (readers don't block writers and writers don't block readers) and also support other RDBMS implementations? Same goes for sequences vs. autonumbering columns. What are you goint to wrap this in?

Sure you can write your own table and increment a value in serial fashion ... but that's not using native functionality. That's returning to technoloogy I implemented back in the 1970s.

> No! You seem to be working on false presumptions. Repeating ad nauseum, I
> advise against complete DBMS-independence.

I repeat it because so far it has not been addressed except in read-only examples involving select statements.

Using oracle packages would not
> impose a severe enough problem with the generality of the DBMS client part
> of the application for me to suggest that they not be used.

But as packages don't exist in any other RDBMS implementation the front-end would need to be recoded. Agreed?

If you need
> numbering, you have to do it DBMS-specifically, or wrap your own.

At which point you are 100% vendor dependent. Any wrap-your-own will create serialization which greatly limits scalability. Agreed?

> The reason may be that the functionality requires too much
> specificity in the product outside the DBMS, or it may be simply be because
> the part of the product outside the DBMS can do it better.

If anything can be done better outside the DBMS then I agree that doesn't belong in the DBMS except as it may be required to guarantee security and integrity if someone accesses the data with another tool. Agreed?

I am not a database bigot. I put functionality in the front-end, in middle tiers, anywhere that it makes sense. The issue from my standpoint is not where functionality resides ... on that we are basically in agreement.

My dispute is with the thought that I can be both vendor neutral and vendor dependant. You can not have your cake and eat it too.

-- 
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 Sun Feb 01 2004 - 15:42:32 CST