James Rogers wrote:
>
> 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.
>
I have made a quite comfortable living writing OO persistence middleware
to alleviate having to depend on an particular flavor or vendor of
database. Business types certainly do care when they need to support
various types of database solution over time on heterogeneous
platforms. Many real-world business people do not want to be married to
Oracle or any other single vendor. More than a few of them have tried
to make that relationship work for them and have decided to try
something different.
> 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.
>
PL/SQL is not a 4GL.
> 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.
De-facto standards are meant to be toppled and should be as soon as they
get lazy. The argument from the other side is quite strong. Standard
solutions in a world that re-invents itself every other Monday are not
enough.
- samantha
This archive was generated by hypermail 2b30 : Mon May 28 2001 - 09:56:24 MDT