If this thread is not too tattered.

The recent discussion regarding Oracle has been most entertaining. I've now
got quite a few new entries in my techo-acronophic-joke list.

In my experience at a former employer, every relational DBMS technology we
attempted to standardize on went financially butts up (at least for a
while). Allbase, then Ingres, then Sybase, then Oracle (too arrogant),
finally Informix. All the while Image just hummed right along. Side-stepping
the relational vs. non-relational debate, the end result was 5 different
dbms have been deployed across the company. This picture amplifies the
encapsulation message. As we distribute computing (both within the
enterprise and external) we must be come increasingly more responsible to
the ownership and replacement costs of our technology decisions.

When will the dbms vendor be content with achieving the best possible
persistent database management system. Could we just allow COBOL, C, Visual
development tools, and standard middleware to meet the rest of our
application needs.

Using some basic IT design principles (encapsulation, the separation of
application concerns) we can achieve and even measure a "replacement cost"
for a single layer of the application. We don't have to toss the code when
we toss the database.

Managers make buy decisions based on many of the reasons we've seen flying
through our intrays (marketing, success stories, promised technological
advances). Managers rarely ever make decisions using "replacement costs".
How much will it cost me to drop this thing. For those organizations
implementing SAP R/3 or PeopleSoft - I'd like to be around when the try do
un-install them.

I've often been suspect of dbms software who also sell (and package)
complete distributed computing solutions. Who's interests are at the
forefront of their agenda's. If Oracle cared only about storing and
retrieving using a clean backward compatible API, then they might have a
better handle on the stability and performance of their database.

So BUY (or use) a database license, encapsulate its access using Atomic
entity-based read/write functions, provide these read/write interfaces using
messaging middleware and who cares where the rest of the solutions go. If
you decide to kick Oracle out the door, at least you wouldn't have to change
every line of code on the desktop, just the lowest level of the accessing
functions. Heck if you're smart you won't have bought their replication
tools, their 4GL, and their middleware too. So how do we handle middleware
replacement cost, when does it end?


Jonathan van den Berg
Premier Software Technologies
fon: 408-257-8757
fax: 408-253-1184
www: www.premiersoft.com