On Mon, 22 Jan 2001, Samantha wrote:
> I have refused to learn PL/SQL or SQL*Plus any other single db vendor
> proprietary language. The world does not need this and I certainly
> don't. I don't mind learning a specialized language for database if it
> works on all vendor's products of a particular class. I occassionally
> learn just enough to write an adaptor to something of my own invention
> that is more general. But I believe I do my customers and employers a
> disservice if I write their business logic directly in some vendor
> proprietary language.
At some point, this attitude gives diminishing returns. I have a strong
preference for standards based implementation, but only when it doesn't
diminish the results in some way. Oracle is nearly as ubiquitous in the
database world as Windows is in the desktop world, so I don't feel bad
about writing some code in PL/SQL when called for, any more than I would
feel bad about writing part of a Windows app in VB if that was best
suited for the job. Considering the shear numbers of people who know
PL/SQL, and the probability that it will be supported for many years into
the future, I don't see a problem with it from the perspective of a
business manager.
Sure, I could do everything outside of the database using JDBC/ODBC and
the language of your choice (and many times I do), but I wouldn't
necessarily do it out of principle. My client is paying for the best
solution to their needs, not for a solution that meets an abstract ideal
that can't be easily justified, particularly when a standardized
solution barely meets the required metrics (speed and scalability are
typically my given primary design goals). Beside which, many "standards"
have fallen by the wayside faster than proprietary systems.
I have to design for scalability and headroom, and so that is where I put
the engineering elegance. I am not religious about language, as long as it
is reasonably clean. A well-written code base in any reasonable language
makes the choice of language really a matter of aesthetics or cosmetics.
In practice, I usually do most everything in open standard environments,
but for sections of a system with critical performance, I am not shy about
diving in and creating a custom tailored solution using proprietary tools.
In PL/SQL land, that may mean that certain complicated transactions are
compiled into the database and accessed using standard APIs in something
like Java.
> Oracle should be a vendor of relational dbms technology not busy locking
> you in to having persistent solutions that work only on Oracle and are
> useless on anything else.
While lowest common denominator solutions may be wonderful for a broad
class of applications, some require tighter integration than you'll find
with a standards based environment. Business types don't care; Oracle is
a de-facto standard to them, unless they have a religious objection. If
Oracle isn't an excellent tool for the job, I won't use it or recommend
it. Fortunately, it is quite adequate as an enterprise database and is
usually the preferred database for many managers.
One could argue that a standard database 4GL could be designed, but that
would defeat the purpose. 4GLs such as PL/SQL reflect the internal
details of the database and abstracting it would defeat most of the
advantages of a 4GL to begin with, since internals vary quite a bit
between major vendors. But there is still a good argument for 4GLs,
since there is a substantial amount of opimization inherent in their
design. Frequently I use JDBC/ODBC for database access instead of
native methods, but I do so knowing full well that it won't hold a candle
to native methods performance-wise; when performance is critical, I go
native every time.
In the business world, Oracle is a de-facto standard, just like Microsoft.
My clients don't want me to sacrifice the business solution on an arguable
philosophical premise. "Standard" means different things to people from
the business world and the software engineering world.
-James Rogers
jamesr@best.com
This archive was generated by hypermail 2b30 : Mon May 28 2001 - 09:56:24 MDT