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

[Quoted] 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

[Quoted] 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 vendorspecific  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 Received on Wed Jan 28 2004 - 18:26:18 CET