NetNews Usenet Archive 1992 #19/NN_1992_19.iso/spool/comp/database/theory/396

Internet Message Format | 1992-08-26 | 3.8 KB

Path: sparky!uunet!dtix!darwin.sura.net!mips!decwrl!deccrl!news.crl.dec.com!pa.dec.com!nntpd2.cxo.dec.com!cookie.enet.dec.com!berenson
From: [e-mail] (Hal Berenson)
Newsgroups: comp.databases.theory
Subject: Re: transaction processing - DBMS vs TP monitor
Message-ID: <[e-mail]>
Date: 26 Aug 92 16:56:13 GMT
References: <[e-mail]>
Sender: [e-mail] (USENET News System)
Distribution: usa
Organization: Digital Equipment Corporation
Lines: 61


In article <[e-mail]>, [e-mail] (Alan Beal) writes...
>Cons  Inconsistent gateways                 More complex interface
>      No heterogeneous support              Lack of standards

There are growing standards in the TP space such as the Multivendor
Integration Architecture (MIA) that was driven by NTT (Japan's largest
purchaser of computer equipment).  Quite a number of major vendors are
working to support MIA, since it is expected to become required for sales
in Japan and the rest of the far east.

Historically the choice of using distributed TP vs distributed DB could
largely be made on where work had to be done.  TP moved the work near to
the data while DB moves the data to the work.  With the growth in
multistatement procedure facilities in database systems, this distinction
is somewhat blurred.  The application running on the PC really just
invokes a database procedure on a server, which does all the work.  This
is essentially the same as what TP systems do.

The TP model generally continues to supply the server side with greater
flexibility of application capabilities, security, and system management
than does the DB model.  A transaction server can do anything that an
application or systems programmer can invent, while DB systems tend to
have restrictive security models, restrictions on what a procedure may
do, etc.  And, of course, the DB model generally only works well for the
native database system.  While gateways do exist to other data, going
through one to execute your procedure is likely to be an order of
magnitude slower than using the TP model with a task that accesses the
data using native mechanisms.  So, the TP model will continue to excel
where multiple data sources are present.

On the system management side the TP model lends itself to tightly
controlled environments where applications can only be changed with great
review and approval.  The DB model lends itself to environments where
programmers operate fairly independently.  The TP model has availability
benefits, where it can route transactions to different systems for
processing.  They can, for example, route the same transaction to two
different servers on alternate sides of the world for parallel execution.
They can transparently route transactions to a hot standby when a primary
node goes down.

The TP model can hide the specifics of a user interface device more than
the DB model.  With the DB model you essentially have to write the
application code n different times for n different devices (dumb
terminal, MAC, Windows, DOS, Application) while with the TP model the
application code remains the same and you just change some UI code (and a
4GL may even be able to hide this from you...of course it may do that for
the DB model as well).

.............................................................................

Hal Berenson

Home: [e-mail]
Work: [e-mail]

-- Disclaimer: Opinions expressed here are my own, not my employer's! If
I happen to communicate with you from work rather than home, its just
for convenience (just like asking for a "daytime phone number") and should
not be construed as representing the views of my employer or its
employees, officers, directors, or stockholders. --