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

From: Daniel Morgan <damorgan_at_x.washington.edu>
Date: Thu, 29 Jan 2004 00:33:04 -0800
Message-ID: <1075365124.32752@yasure>

Joe Weinstein wrote:
> Daniel Morgan wrote:
>

>> Joe Weinstein wrote:
>>
>>>> Unless I interpret the above as meaning you've changed your mind I 
>>>> am lost as to your original intent when you wrote that you counsel 
>>>> against complete DBMS dependence. Seems like you've changed from 
>>>> "dependence" to "INdependence". Was the original a typo or did I 
>>>> misunderstand you?
>>>
>>>
>>> No, the original is correct, that I council *against complete DBMS 
>>> INDEPENDENCE*.  The 'IN' is intended, and in the original post. I also
>>
>>
>>  > council against complete DBMS-specificity, or even using the DBMS for
>>  > everything it can do.
>>
>> You are mixing together multiple incompatible concepts. Lets take them 
>> one at a time.
>>
>> Complete DBMS independence means utilizing those vendor specific 
>> functions that optimize security, performance, and scalability. Good 
>> so far.
>>
>> Having done the former ... the second is logically impossible. Once I 
>> use a vendor specific function, for example in Oracle packages, I have 
>> code that can not be moved anywhere else without a rewrite. You can't 
>> have it both ways.

>
>
> Please try one more time. In your first sentence you imply you'll take
> several concepts one at a time. Your next sentence lists three possible
> candidate 'concepts' all together. Then your last sentence only refers to
> two, presumably security and performance. (What happened to scalability?).
> I don't understand what you're saying. Your first sentence doesn't make
> sense to me, and I think we unintentionally misunderstand this below:
>
> In my meaning,
>
> "Complete DBMS *dependence* means utilizing (all) those DBMS-vendor
> specific
> functions that optimize or implement security, performance, and scalability
> (and other stuff)." Perhaps it also means "Relying on at least one DBMS
> vendor-
> specific feature in a way that makes the system practically unable to adapt
> to another DBMS".
>
> 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, that syntax which provides the same
> semantics in any DBMS.
>
> It is also true that a system could be completely dependent on a given
> middle tier product if it used all the vendor-specific features of
> that product. What we have been talking about is what degree of
> DBMS independence a system should maintain. *Some* independence is
> possible and good, and maybe even unavoidable, such as the common
> semantics (for the most part) of the shared SQL language. Independence
> is good because it broadens the market for the system and lowers the cost
> usually. Lots of such successful systems exist.
> Some dependence is unavoidable, such as having something in the DBMS
> client that speaks the client-DBMS wire protocol. Some
> dependence/independence
> is optional, such as a vendor's stored procedures. Should a system use
> them, or stick to fresh SQL92? I would generally expect stored procedures
> would be better, even if the system had to have multiple analogous
> subsystems to attempt to duplicate functionality to different DBMSes.
> On the other hand, there are some functions that the DBMS can do,
> in a vendor-specific way, that I would advise against. Indeed, there
> are some functions that the DBMS can do in a completely generic way,
> that should nevertheless be done elsewhere. Oracle's top TPC-C benchmark
> is an example of this last category.
> Joe

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.

In Oracle, for example, there is no better place to put code than in a package; for numerous reasons. No other database vendor has the concept ... therefore throw packages away.

In Oracle and DB2 the best way to do numering is with a sequence. SQL Server and Sybase don't have them so throw sequences away. Of course SQL Server and Sybase have autonumbering that Oracle doesn't have so throw autonumbering away too. Guess we won't have any surrogate keys except by wrapping your own ... now that's generic. All we need to do now is recompile for every operating system.

Sorry Joe ... but your attempt to construe development to sell your company's product is a great way to do some things. Creating high performance scalable databases isn't one of them. Not once has Oracle won a benchmark contest with BEA using generic code. No one else will either.

-- 
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 Thu Jan 29 2004 - 02:33:04 CST