mjr@well.UUCP (Matthew Rapaport) (08/08/87)
I've been following the discussion about database consistency and
concurrency with interest. As an applications programmer, I can
sympathise with G. Puckering's sentiments. Since the applications
design can account for consistency problems itself, the DBMS engine
could (if the option were available) be optimized for concurrency
at the expense of potential inconsistency. As a product, Informix
seems to belong in the small to small-medium database market (thats
< 100,000 records, usually in < 100 tables, perhaps on a mini or
super-micro (or network), with 3 to 20 users and 80 to 400 meg. of
disk). In this environment, it is not unreasonable to expect that
application developers could maintain control of and responsibility
for data consistency.
But one of the chief presuppositions of large DBMS systems is that
the database itself will support applications not conceived when the
logical architecture of the database is designed. In these environments
those responsible for the integrity of the data must insure that every
application connecting to the database will receive equal treatment
with respect to both inquiry and update operations. Specifically,
the DBAs must guarantee that no database operations, no matter how
carefully or sloppily they are submitted to the DBMS will corrupt
the database. Since you cannot "turn off" degree-3 consistency for
one application and leave it on for others, applications designers
must live within its performance constraints. Even where the degree
of consistency could be lowered (say for a batch job run at nite
when no other applications were EVER using the DBMS), I doubt that the
DBAs would want to trust their jobs to the integrity of an application
program, especially considering that the program may be "enhanced"
here and there with the DBA having no guarantee that some integrity
threatening bug was not introduced. Furthermore you have the problem of
what to do when the next hi-throughput nite-run batch application is
conceived and its development given a go-ahead, etc.!
For my money (and job) a strict serializable-recoverable schedule is
the only way to go. If I'm not getting the performance I need from
an application I work with the DBAs. They can tune the physical
database to some degree, and they've helped by suggesting ways I might
re-work the application design to give better performance up front, etc.
If all of this still isn't enough, well compromise is the way of the
world, and most corporations are more than willing to pay a performance
penalty in exchange for a guarantee of consistent data. You could
always upgrade your hardware...:-)
P.S., I want to thank Dr. Hadzilacos for his book (he recommended it
to me here) "Concurrency Control and Recovery in Database Systems".
I've read about half of it now and its great. I highly recommend it
to anyone here who is investigating this subject.
Matthew Rapaport
mjr@well ({ptsfa|dual}!well!mjr)
CIS: 70371,255
Source: BEC872