Quirk (quirk / syntac.net) writes:
> You can always write bad code, my point being that if you are using a
> commcial SQL server, such as Oracle, you should abstract your data
> access so that you can use something else instead down the road, you
> can do this with your own wrappers through elegent coding, or use a
> class such as PEAR::DB (for PHP), depending on what your application
> requirs. Efficiency is very relative, eficiency of what? Code
> Executution? Application Extension? Interoperability? Tip: The first
> is not always the most important.

This may sound good in theory. Real life is different.

One should keep in mind that few tools are so extremely powerful to make
things go really slow as database engines.

There are of course applications where portability is a requirement. I 
once had contact with a small company who authored a system for producing
financial reports for big corporations. Their philosophy was that they
could not mandate which engine to use, so they aimed at portability. I
guess that was a fairly small system.

The system that I work with now runs only on RBDMS: MS SQL Server. This is
a business-critical system for our customers, and if I had support multiple
platforms, I would not be able to give our customers acceptable performance,
nor acceptable functionality. At least not to acceptable prices.

A competitor of ours were working on a replacement for their current
system - which dates from the end of the 1980s - and they worked just
along the line they suggested. Their owners poured in around 250
million SEK into that work, and the system is far from completed. That 
competitor recently fired about 80% of their staff, and that new
system will never be completed.


-- 
Erland Sommarskog, SQL Server MVP, sommar / algonet.se

Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techinfo/productdoc/2000/books.asp