Re: Myth of the database independent applications (Was: Are you using PL/SQL)

Serge Rielau wrote:

> The very fact that deep exploitation of the DBMS is preached as a
> "requirement" drives the app vendors away.

Not been my experience.

App vendors make decisions based on cost-benefit-risk analysis. They, for the most part, ignore the hyperbole generated by professional marketers and public relations wonks.

> Why would an app vendor want to be held hostage by any specific database
> vendor just to get a performance improvement that Moore's law will fix
> for them in short time anyway?

You set up a straw man and you knocked him over: Congratulations. Customers may feel they are being held hostage. But third-party apps vendors do whatever they feel will generate the most revenue. And usually that revenue includes support and consultants so they view the potential problem as an opportunity.

You might want to look at whether your company, for example, has traditionally made more money selling databases or database consulting.

> Why would customers put themselves into a position where the vendor can
> dictate the support price upon next renewal because the customers cannot
> threaten to change the supplier and the vendor knows that all to well.

First it was vendors and now customers. You've changed horses midstream. And now I agree with you. They shouldn't. But they have, they do, and they will. Because best-of-breed applications are written to exploit best practices.

> The premise of SQL was and is that it's the DBMS' job to optimize. It is
> not the app developers job to write e.g. EXIST instead of IN to achieve
> performance.

That truly isn't the issue and I think you know it. All major RDBMS optimizers can handle EXISTS and IN. What they can not handle is differences in locking, differences in isolation levels, differences in how logging and temporary objects are implemented. And, for example, the optimization created by packages that other products don't have.

> If vendors cannot agree on a procedural language then the customers
> cannot be blamed for refusing or at least minimizing its usage.
>
> Cheers
> Serge

Customers or vendors? Again your are mixing them up. Customers don't write code they purchase projector-ware.

I see no reason why vendors should agree on a procedural language. If that were a requirement IBM and Microsoft could hold Oracle hostage to their lesser capabilities. No FORALL, no user defined operators, no user defined type bodies, etc. That is not in the interest of the customers who benefit from the competitive environment where you guys get to play catch-up and Oracle is forced to aggressively enhance their products to maintain their lead.

Viva la difference.

-- 
Daniel A. Morgan
University of Washington
damorgan_at_x.washington.edu
(replace x with u to respond)
Puget Sound Oracle Users Group
www.psoug.org