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

> The market drives standardization.> If vendors of do not agree on standards then the market abandons the> fractured interface. That is exactly what is happening. One reason why> apps are written in Java and abuse DBMS as mere file systems is that> vendors have not been able to keep SQL standardized. This is not the> first time this happens and it won't be the last.

Actually, application vendors are driving that standardization, not
the consumers. Application vendors are those who are trying to make
the database into an off the shelf commodity. So far, the application
vendors have not been really successful in their endeavors.

> > The very fact that deep exploitation of the DBMS is preached as a> "requirement" drives the app vendors away. 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?

Because the competing vendor who does write an application using a
specific database software will outperform those who do not and Moore's
law is not really counted on in the corporate IT.

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

Customers rarely can threaten a supplier. I was driving Chevy Cobalt
before moving to New York City. Both the car dealer and me knew that
cars are expensive and it would be a major expenditure for me to buy the
new ones just because I am unhappy with some detail. Throwing away an
application system is a major undertaking that would require changing how
the company does business, retraining and conversion of the application
data from one application system to another. The most successful
application systems (SAP, Peoplesoft/Oracle, JD Edwards, Lawson) are all
tied up to a specific major database which they recommend to the
customers. I heard of no SAP customers ever converting to JD Edwards
or vice versa.

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

Actually, I believe that is application developers responsibility.
Application developer can not distance himself from his application and
not care how it performs. Application developers usually write
applications for specific platform, until we reach the same state of
maturity as reached by file systems. System services to open or write
files will function equally on all file systems and there are very few
companies that sell file systems (Symantec/Veritas and HP/Polyserve
being the only ones I know of). Unfortunately, databases have not yet
reached that level of maturity, but the field is increasingly leveling.

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

Customers? No, customers are not the ones driving the market here.
Application vendors are. Buying PeopleSoft was a response to SAP's
experimentation with their own database and claiming "database
independence".