|
David Dreyfus
Database Systems Group
DTN 381-2893
DEBIT::DREYFUS
26-September-1988
Review of Oracle's V6.0 with TPS Announcement
The enclosed Internal-Use-Only information is based
upon Oracle publications and press reactions to the
Oracle 18-JUL-1988 announcement. As this note contains
both fact and impressions, some of the statements I
make are debatable.
1 What Oracle Announced
On July 18, 1988, Oracle announced version 6.0 of
the Oracle relational DBMS and TPS (a transaction
processing subsystem). According to Oracle, the new
and upgraded products provide fault-tolerance, online
backup and recovery, online reconfigurability, and
high performance. Some of the lower level functions
that have been introduced are fast commit, row level
locking, a read-consistency model, new DBA tools, a
new report writer, and a new query language (PL/SQL).
For the most part, these new capabilities have been in
the VAX Rdb product set for years. Oracle requires the
customer to purchase an additional product, TPS, to
get these capabilities.
1
2 The market reaction
The most exciting part of the announcement was
Oracle's benchmarking technique which allowed them to
show 49 transactions per second (TPS) on a 6240 with
a 0.1 million record database. Oracle also showed 265
TPS on an IBM MVS 3090 Model 600E with a 0.1 million
record database. These tests used a heavily modified
version of the TP1 benchmark. The results bear no
relation to any number Digital, or any other vendor,
has produced.
The press and consultants have had a field-day
discrediting Oracle's benchmark results. Oracle has
had a very difficult time finding auditors who would
verify the results (Computerworld, July 18, 1988).
In fact, they searched for multiple auditors in an
attempt to get their tests verified.
Lawrence Ellison, President of Oracle, claims that
their TP1 is a "Debit/Credit benchmark, absolutely the
same as Tandem's." (Computerworld, August 1, 1988).
However, unlike Tandem, the article says, Oracle did
no front-end communication, no mirrored journaling, no
simulated terminal networking (transactions initiated
from main memory), etc. According to consultant Omri
Serlin, "Oracle has gone to such an extreme in what
they have done. It had no on-line flavor whatsoever."
The author, referring to the material, says, "Yes,
ladies and gentlemen, it was a thick document, but we
should read it as well as weigh it."
Oracle claims that Codd and Date have audited their
benchmark. No report is available from Codd and Date
who generally refuse to comment when asked about the
audit (Computerworld, July 18, 1988). Many articles
that provide analysis of the Oracle announcement
generally dwell on the poor benchmarking techniques
and ethics of Oracle.
2
3 Examination of Oracle's announcement
3.1 Fault-tolerance
Oracle now claims that their DBMS is fault-tolerant.
From a reading of their promotional literature
and other documents, this means that they now have
automatic recovery if a disk or CPU crashes; they can
continue to run in a VAXcluster environment if a CPU
is off-line; and they can continue to run even if part
of the database is off-line.
In all of these areas, Oracle is playing catch-up to
VAX Rdb/VMS. Rdb has had VAXcluster automatic recovery
capabilities since V2.0, released November, 1985. Keep
in mind that Oracle is releasing the first version of
this functionality.
3.2 Online backup and recovery
Oracle now has online backup, the ability to backup
a database while users are still running database
applications. However, Oracle uses the native backup
command provided by the host operating system. On a
VAX, this is VMS backup. VAX Rdb uses its own backup
format that is based upon the structure of an Rdb
database for greater speed.
In addition to online backup, VAX Rdb also does
incremental backup. Incremental backup increases
backup speed and ease of maintenance by reducing the
amount of data that needs to be backed-up.
We have taken advantage of our position as both the
hardware and SOFTWARE vendor to provide the fastest
and most reliable backup capabilities of any database
system on the VAX. We can backup multiple areas
(similar to Oracle's tablespace) at the same time,
concurrently streaming three tape drives. Rdb still
wins the maintenance battle.
3
3.3 High performance
Oracle would have you believe that they are the
only high performance database system. Their recent
testing, however, doesn't prove it. The TP1 test, as
they ran it, is meaningless and should not be confused
with the Debit/Credit test that Digital ran with Rdb.
It is very difficult to rely upon any of Oracle's
performance numbers and the conclusions that they draw
from them (such as linear scaling on SMP machines).
They generated all the transaction from memory (no
users), there was no communication costs, and no
application costs. No auditor with experience with
relational databases would verify their tests as
conforming to the Debit/Credit standard.
There are many tricks that a vendor can play to
generate high TPS rates. It surprises me that
Oracle's are as low as they are. In an environment
where IO, locking, and communication overheads can
be eliminated, it is no great surprise that high
performance and linear scaling can be observed. Give
no credence to the Oracle results.
Rdb V3.0 customers, however, have been very pleased
with the performance of their new version. Check
announcement materials for more details on all the
benefits of V3.0. Also use the RDB_VMS_COMPETITION
notes file and recent editions of Competitive Update
for detail. (Competitive Update: July 12, 1988; August
22, 1988. Sales Update: July 12, 1988).
4
3.4 Fast Commit
Fast commit allows transactions to commit without
writing the data pages to the database. The changed
data pages are stored in memory in the expectation
that future transactions will access the same page.
This is a method for reducing IO per transaction.
If system failure occurs, this method uses the log
file to redo committed transactions. Often, this will
cause much longer recovery times than Rdb.
In large, OLTP, databases this feature probably has
no usefulness unless the user of this feature just
wants to show good benchmark results. Large OLTP
applications will touch many different pages causing
any cached pages to be written to disk. In this
scenario fast commit will have no significant impact.
Fast commit does help if you run benchmarks for short
duration so that no IO is ever done (all the dirty
pages stay in memory until after the benchmark is
run). Fast commit can help on small databases where
the database can reside in real memory. And, fast
commit can help if access to the database is not
random. The extent that fast commit helped Oracle
in their benchmark is probably a measure of their
divergence from the Debit/Credit benchmark standard.
3.5 Row level locking
With TPS, Oracle has introduced row level locking for
the first time. In previous releases Oracle claimed
that they had row level locking. In reality, they
locked the entire table for update. There may be other
features or benefits that Oracle claims that they have
that they haven't yet implemented.
Rdb has had row level locking since version 1.0. Rdb
has been the leader in providing high performance
techniques for OLTP.
5
3.6 Read-consistency model
Oracle likes to claim that their read-consistency
model is unique. In a sense it is. It is the only one
that forces all reads through a single before image
log.
Rdb has had read-consistency through SNAPSHOT files
since version 1.0 in 1984. Rdb, however, provides a
great deal more flexibility in its implementation.
Perhaps the most important difference is that you can
have separate snapshot files for each database area
and can place these snapshots on different disks to
eliminate the file contention that would result with
the Oracle implementation.
3.7 DBA tools
Oracle is finally trying to make the running of an
Oracle installation easier. They have created a single
interface that allows the startup and shutdown of
the six or so processes that must run in order to
support even a single user (at least four of these are
detached processes that support multiple users).
Their DBA tool also allows some small amount of
database monitoring capability: reads, writes,
commits, locks, IO, etc. The granularity of these
items is not clear. Some of the information is only
available on a per-process or per database basis.
Rdb has recognized the importance of simple database
administration for a long time. That is why Rdb
has the Rdb Monitoring Utility (RMU). RMU provides
sophisticated statistics and graphs to help monitor
and then tune the database for maximum performance.
6
3.8 PL/SQL
PL/SQL is an Ada-like language to which users must
convert in order to get high performance from
Oracle. Oracle presentations go into great length
on the conversion of SQL to PL/SQL. According to
the president of Oracle, PL/SQL gives the user a 15%
performance increase over regular Oracle.
By using PL/SQL the application is no longer based
upon the SQL standard and is no longer portable across
DBMSs. The customer is tied to Oracle.
Compare this to Rdb where high performance is built
into the product and not through language enhancements
(PL/SQL) and add-ons (TPS). In addition, high
performance Rdb applications can be written in SQL
and retain portability across database platforms.
Although Oracle may try to sell this product as a
TP monitor, it is not. In addition, it is not clear
how well (if at all) this product will work with
existing TP monitors offered by Digital. See the
article "Selling OLTP Against Oracle" in XXX for more
information.
4 Summary
On July 18, 1988, Oracle announced a number of new
features that improve Oracle's DBMS performance.
Most of these features require the purchase of a new
product, TPS, that costs an additional $75,000 on a
VAX 6240.
The benchmarks that Oracle produced with this new
software demonstrate very high TP1 performance but
are not comparable to Digital's Debit/Credit benchmark
results. Any comparisons between the two tests are
meaningless.
7
The new features that Oracle introduced have generally
either been in Rdb for years or have been added to
Rdb in version 3.0. In addition, Rdb generally has
a more complete and flexible implementation that
should provide users with higher performance than that
available with Oracle systems.
8
|
|
David Dreyfus
Database Systems Group
DTN 381-2893
DEBIT::DREYFUS
26-September-1988
Selling OLTP against ORACLE
On July 18, 1988, Oracle announced a number of new
features that improve Oracle's DBMS performance.
Oracle now sells the idea that they can provide OLTP
(On-Line Transaction Processing) solutions. The claim
is supported by the announcement of TPS (Transaction
Processing Subsystem), a $75,000 add-on for a VAX
6240. In fact, TPS brings little to the customer that
is not already available with VAX Rdb/VMS V3.0.
The benchmarks that Oracle produced with this new
software demonstrate very high TP1 performance but
are not comparable to Digital's Debit/Credit benchmark
results. Any comparisons between the two tests are
meaningless. In fact, most of the OLTP characteristics
of the Debit/Credit benchmark were ignored in Oracle's
tests.
Oracle can only satisfy a small portion of customers'
OLTP needs. Digital has the architecture, products,
and experience to support OLTP applications. Where
Oracle is introducing first-time capabilities, Digital
has mature products and many satisfied customers.
1
1 Selling OLTP
1.1 Capabilities
Transaction processing (TP) is much more than driving
high TPS (transactions per second) through a database
system in a controlled benchmark environment. TP is
driving high TPS through a complete computing system
in a dynamic environment.
The TP system much be able to handle many users using
many different types of applications while still
demanding high performance at minimal cost. In order
to satisfy this environment, the database system must
be designed to handle complex database designs and
a wide variety of transaction types. This is the
exact opposite of the environment described by the
TP1 benchmark used by Oracle. It is also the type of
environment that VAX Rdb is designed to handle.
Other critical capabilities of a TP system are high
levels of security for applications, security for
users, dynamic tuning capabilities, and the ability
to queue work for later processing. It is only
through the use of a TP monitor that many of these
capabilities are realized. These too are capabilities
that Oracle lacks.
As Digital improves its TP capabilities, important
functions will be moved into the operating system.
For the customer, it is important that their TP system
continue to work as the underlying system services are
enhanced. It is important that their database system
continue to work with and take advantage of changes
to the operating system. The level of integration
required for TP systems is much greater than that
required for ad-hoc reporting and 4GL applications.
As the developer of the operating system, database
system, TP monitor, forms, etc Digital is uniquely
qualified to provide the required capabilities and
integration for TP applications.
2
1.2 Experience
Digital has been selling OLTP products and solutions
for years (one consultant's estimates put Digital
OLTP revenue at 1 billion dollars). Oracle is just
entering the market. As a result, Oracle has a number
of problems delivering OLTP solutions. For starters,
TPS, which is required for all the features described
above, is not yet available. After all the delays
in getting V6.0 out, who knows how long it will take
before TPS is delivered. In addition, there is some
doubt about the reliability of Oracle products.
In contrast, Rdb, Transaction Processing (TP) monitors
(ACMS and DECintact), forms products (FMS and TDMS),
and the other components for OLTP from Digital have
been released for years. So, a big difference between
Oracle and Digital in OLTP is experience.
1.3 Architecture
OLTP requires an architecture and products in order
to deliver solid solutions that will protect the
customers investment for years to come. Digital has
an architecture (DECtp) and the products. Oracle has
neither.
All that Oracle can offer is a DBMS. It is not clear
what forms package Oracle can offer. Their SQL*FORMS
is not suitable for OLTP for lack of performance.
It is not clear that PL/SQL introduces a new forms
package or will work with any existing forms package.
Oracle doesn't have a TP monitor. Thus, while they may
provide efficient database services (no guarantee of
this), they may not provide efficient application or
form execution services.
Digital can support hundreds of users on a MicroVAX
with a product like ACMS. It is not clear that Oracle
can. In addition, with a product like ACMS, forms
processing can be distributed to multiple inexpensive
CPUs for a distributed OLTP solution. TP monitors
3
that integrate with Rdb allow a small amount of
VAX resources to provide high performance and fast
response times for hundreds of users.
1.4 Development
Oracle will probably require customers to use PL/SQL
for any OLTP application. Otherwise, the communication
costs will be excessive between applications and the
database. This solution uses a 3GL (Ada-like PL/SQL)
and is proprietary. An Rdb solution can use either
a 3GL approach with DECintact or a 4GL approach
with ACMS. In either case, database access is still
provided by industry standard SQL.
All the pieces of an OLTP solution should be tracked
through a data dictionary. With CDD, Digital offers
a distributed active data dictionary that tracks
applications, databases and forms. CDD works with
database objects and non-database (RMS) objects
and acts as the integration point for many Digital
products. Oracle is not nearly as advanced in this
area, providing little more than the system catalogs
every database management system provides.
With Oracle, form, application, and database
definitions cannot be easily shared between
applications or databases. With VAX Rdb, definitions
for forms, applications, and databases are centralized
and shared.
Another important part of OLTP is the management of
the database itself. Oracle has tried to make this
easier with their recent announcement. This includes
on-line backup and a DBA tool.
4
1.5 Management
OLTP databases are often complex and dynamic. They are
complex because they support multiple types of users
with a wide variety of transaction and record types.
It is unfortunate that neither TP1 or Debit/Credit
benchmarks measure this because it is in exactly this
type of environment where Rdb excels.
Unlike Oracle, Rdb provides a sophisticated monitoring
and tuning tool with RMU. With RMU the DBA can monitor
disk usage by table and partition data across the
available disks to provide low IO rates and optimum
performance. Oracle doesn't have the capability to
control the placement of records from a single table
on multiple disks. The key here is control. Oracle
does have some capability for a table to use multiple
disks. The question is, can the DBA determine what
ranges of values go on each disk.
Another important area of database management is the
ability to control page sizes on disk and re-use pages
as the database changes. Oracle uses fixed page sizes
which may not necessarily be the correct size for
maximum database performance. Although it may have
changed in this new version, Oracle also doesn't allow
space deleted from one table to be automatically used
by other tables. Rdb, of course, allows both flexible
page sizes and automatically reuses space.
One of the biggest differences between Oracle and
Rdb are in the area of space management. Oracle uses
the IBM, DBA intensive, approaches where space must
be preallocated for databases and tables. If table
space fills up with Oracle, data must be unloaded and
reloaded after new space is allocated. Rdb, of course,
uses the Digital style of file management where space
is allocated as needed and the database is extended
dynamically.
5
Rdb recognizes that OLTP is dynamic. You can't know
how much space to allocate beforehand. You also don't
want to allocate space that isn't going to be used
right away. Finally, you don't want to hire people who
spend all their time worrying about managing database
disk space allocations.
Oracle may be very easy to use from an end-user point
of view. Most products are. The difficulty is managing
the database and application development. It is in
these more difficult areas that Digital excels.
6
|
|
David Dreyfus
Database Systems Group
DTN 381-2893
DEBIT::DREYFUS
26-September-1988
Combating Oracle's Marketing Strengths
Like the Sirens of Greek mythology, Oracle has a few
high level messages that can be difficult to overcome
when selling against them. The difficulty increases
considerably when Oracle has had a chance to set
expectations in the account.
The messages are quite seductive until you really
understand what it is that Oracle is saying and, more
importantly, not saying. We must show the customer
that Digital understands what is seductive about
Oracle's promises and can deliver the promise better
than Oracle.
This involves showing the customer that Oracle is not
actually living up to the expectations set by their
messages and, in fact, that a solution based upon
Oracle may be counter-productive.
1 Portability
The "Oracle is portable, runs on many machines,
and provides hardware independence" argument goes
to the heart of the software/hardware dependency
issue. Oracle uses prospects' belief that they a)
want to be independent of their hardware vendor and
that b) Oracle can provide this independence. By
working across most computing platforms, Oracle tells
prospects that they can move their applications to the
newer, faster hardware platforms.
1
Rdb, by contrast, only works on VAX/VMS and therefore
locks the prospect into VAXes - or so goes Oracle's
argument. These are difficult arguments to overcome.
Sometimes they take on a religious nature. There are,
however, a number of ways to respond.
1.1 Application layer portability
The real cost to users is application development
time. Users want to be able to move their applications
to new hardware without rewriting it. Thus, customers
want to write software that is hardware independent in
order to effect this portability requirement.
This does not, however, require that the same system
software run on each hardware platform. What is
required is that system software provide an industry
standard interface and that the tools used to produce
the software do the same. With VAX SQL and the many
industry standard languages it integrates with,
Digital provides application portability. Most, if
not all, the software vendors that provide "portable"
software build it on VAXes with portable tools and
languages offered by Digital.
Oracle fails to explain (unsurprisingly) what is given
up by using a major piece of system software (the
DBMS) not provided by the hardware/operating system
vendor.
Rdb provides application portability and takes
advantage of the richness of the underlying platform.
In order to produce a piece of system software that
runs on all platforms, Oracle fails to use a VAX
to its greatest advantage. Oracle must build to the
lowest common denominator (a PC DOS system?).
By selecting Rdb as the database engine, the customer
has both the best database for VAXes and application
portability - a win-win situation.
2
1.2 Software vs hardware dependency
The real threat to application portability and
development is software dependency. Customers are
dependent on the applicability of the tools they
select in order to complete their development goals.
They are dependent upon the continued maintenance,
support, and improvements of database and application
runtime systems for application execution.
This dependency is OK as long as the tools and runtime
systems meet customers' needs at an appropriate price.
However, if the tools and runtime systems fail to meet
expectations, customers will want to migrate their
applications to a different software platform. It is
during this migration that software dependency becomes
a major issue.
All 4GLs are proprietary and therefore cause a
dependency. The difference is that Digital offers
a standard environment for application development
that doesn't require the use of a proprietary 4GL.
Applications can be written in a standard language
with SQL with calls to a forms package or built with
the VAX COBOL Generator. Oracle applications that
use a form interface require the use of SQL*FORMS,
Oracle's proprietary 4GL.
VAX Rdb supports a whole range of 4GL tools. This
eases migration for applications that require new
tools because both the new and old tools can continue
to use the same database. If Oracle's tools are no
longer effective, the customer must select a new tool
from a very short list of third-party products or the
customer must migrate to a new database system.
In order to provide an environment that further
minimizes the cost of software dependency, Digital
supports broad, standardized interfaces to many
important system services. A partial list includes
SQL, RDA (remote database access), X-windows, PHIGS,
3
and OSI. Oracle does not support nearly as many
standards as Digital.
Oracle customers are trapped by Oracle's proprietary
software environment. Their SQL is not ANSI or DB2
compliant. The addition of so many extensions to
Oracle's SQL makes their SQL non-standard. In order
to improve performance, Oracle's customers must use
PL/SQL (which is both non-standard and incompatible
with Oracle's own SQL). The tools used to build
software (4GLs, SQL*FORMS, PL/SQL, dictionaries,
precompilers, etc) are not industry standard.
If we can get the customer to see the software
dependency issue, we can offer the VAX Rdb platform as
a solution. The lock-in is much less, the dependency
is much less, and there is a far greater variety of
tools and software with which to integrate and build.
1.3 Broad based integration
Oracle has a very narrow product set in comparison to
that which is available from Digital. Digital has
a wide variety of office automation, commercial,
scientific, CASE, realtime, and OLTP software that
integrates with Rdb. The level of integration and the
variety of tools and applications will only increase
in the future. A decision to go with Oracle is a
decision to go with a narrowly defined product set
and to forgo the richness of the VAX environment.
4
2 A PC product
Another convincing Oracle argument is the availability
of a PC based DBMS. As PCs become the desktop device
of choice for many users, prospects want database
software to run on the PC. Rdb, as you know, only runs
on VAX/VMS.
The first step in combating this argument is to
assess what is really needed on the PC. Does the user
really need the data to be stored on the PC or will
applications and application development suffice? We
need to convince the user that VAX stored data is OK
as long as PCs can be used for application development
and execution.
The argument for not storing data on the PC is
that the data can't be shared, data management is
complicated, backup is difficult, and integrity is
diminished. By storing data on the VAX, backups are
easy, data can be shared, and high performance can be
achieved.
Using standard languages and DECnet-DOS, users can
build applications on the PC for PC use or VAX
use that connect to a VAX and Rdb. The "Colonial
Management Testimonial" (available at a Lit. Center
near you) talks about one company's experience doing
just this.
With SQL Services, program announced July 19, 1988,
application builders will have a direct SQL connection
from their favorite workstation (PC, Unix, DECwindow,
etc) to Rdb. SQL services will provide a client-server
environment to PC database users. A VAX Rdb server on
VMS will handle the needs of multiple PCs quickly and
efficiently. Applications on the PC will be written
to a standard API (application programming interface)
so that the same application can be executed on any
supported workstation without change.
5
In addition, there are existing third-party products
providing PC to Rdb connectivity. Currently, Multiplex
(Network Innovations) allows users to access VAX
Rdb and move data into multiple PC data formats.
Powerhouse (Cognos) and Today (BBJ Computers) allow
users to build applications on their PCs that access
VAX Rdb.
3 Integrated SQL toolset
Oracle likes to show how all their tools talk SQL to
the Oracle DBMS. This gives prospects the impression
that Oracle is industry standard. This argument should
fail with sophisticated prospects; but, they don't
make all the decisions.
The argument can be attacked in a variety of ways.
3.1 It's not SQL
SQL is a data definition and manipulation language.
As such, it is not capable of providing a complete
interface between applications, tools, etc and
the DBMS. Any extensions made to SQL to allow this
connection are, by definition, not standard. That they
may be called SQL is marketing hype. The user cannot
take Oracle tools that talk SQL and connect them to
another SQL database (say Rdb) and expect a working
product.
6
3.2 Third-party integrated tools
One of the great advantages of Rdb is that it is
accessible by a large variety of third-party tools.
These tools are often better integrated than Oracle's
and work very well with Rdb. Many of them even speak
SQL and many of them work with RMS.
VAX Rdb's ability to support a large number of tools
increases Rdb's value to the customer. While an
Oracle customer is limited by Oracle's development
tools, an Rdb customer has a very wide range of tools.
Sometimes it takes more than one type of tool to solve
a problem.
3.3 Separate the DBMS and tools
The key to selling against Oracle may be to divide
and conquer. We need to get the user to consider the
DBMS separately from the 4GLs and tools. Oracle will
get their customers to buy their database system on
the strength of their tools. Oracle demonstrates their
tools - it is what users will see first.
We need to show that Rdb supports an excellent
tool set with products from Digital and third-party
companies. We also need to impress upon the customer
the importance of their DBMS selection. Position
Oracle as a single-tool, 4GL company with a database.
If both system administration and end-user groups can
be involved in the product evaluation, the fact that
there are really two different purchases may become
clear. We can then sell the end-users on the idea
that Digital can find them a wide variety of excellent
tools. We can sell the system administration people
Rdb's ease of maintenance, tunability, and performance
features. We can satisfy both groups by selling a more
complete package than Oracle.
7
4 Performance
Oracle has jumped on the OLTP bandwagon with their
version 6.0 and TPS (transaction processing subsystem)
announcement. As part of this announcement, Oracle
released the results of their TP1 benchmark. Oracle
is trying to use this benchmark to confuse the market
about the differences between TP1 and Debit/Credit.
They are also trying to confuse the market about their
relative performance with VAX Rdb.
The features added to version 6.0 and TPS are also in
VAX Rdb. However, where Oracle has placed much of its
functionality in add-ons (TPS) and languages (PL/SQL),
which requires applications to be rewritten to take
advantage of the enhancements, VAX Rdb has performance
built into the product so that applications can
continue to work without change.
Unlike Digital's Debit/Credit benchmark, Oracle did
no front-end communication, no mirrored journaling, no
simulated terminal networking (transactions initiated
from main memory), etc. According to consultant Omri
Serlin, "Oracle has gone to such an extreme in what
they have done. It had no on-line flavor whatsoever."
The author, referring to the material, says, "Yes,
ladies and gentlemen, it was a thick document, but we
should read it as well as weigh it."
For a more detailed analysis of the Oracle
announcement, read the report titled "Review of
Oracle's V6.0 with TPS Announcement" in XXX.
8
5 The 4GL demo
Oracle uses their 4GLs and tools to sell the database
system. They talk SQL and portability to comfort the
user into an Oracle purchase. They use the 4GL to show
ease of use and productivity.
Customers who purchase Oracle because of the 4GL walk
into Oracle's trap. In an effort to reach some level
of independence, they sacrifice all independence by
getting locked into a proprietary Oracle software
environment.
The first way of addressing this issue is to outline
this progression to the customer. Help them "see
the light" and separate the DBMS and 4GL purchase.
Through a combination of standardized hardware and
software platforms as well as partnerships with third-
pary companies, Digital can maximize application
portability and minimize the customer's involvement
with proprietary dependencies.
9
|