Beginning SQL

11
Transactions
When you move out of the realm of single-user databases, ensuring the validity of the data from
the time you start to make modifications to the time you finally finish making modifications
becomes critical. Modern databases may host hundreds or even thousands of users and even host
programs running autonomously and automatically without human input or intervention. If each
of these users and programs can independently make changes to data throughout the database,
the probability of collisions between users updating the data becomes almost a certainty.
Even in so-called small databases, it isn’t uncommon for the majority of users to all be using a
small segment of the data, typically the most recent data. In many cases, older data is used for historical
purposes only, examined only for reports about past performance. In many databases, the
data entered in the last month or even the last few days is far more likely to be updated and examined
than data from a year ago. An insurance company has thousands or even millions of claim
records but is actively working on only a few hundred or thousand right now. A manufacturing
company may have hundreds of thousands of orders over the last 10 years but only a few hundred
that are currently being processed. A hospital has thousands of patient records in their database
but only a couple hundred people currently in the hospital and a few hundred more being seen on
a daily or weekly basis.
Most users need to see only these active records. Users add new records, other users immediately
use these new records to cause related processes to occur, other records in other tables are updated,
or new records are created, all causing a big ripple effect caused by some triggering event such as
an accident claim, a product order, or a patient admission. Everybody needs concurrent access to
this small set of new data, and then as the claim is processed, the product is manufactured, the
order is shipped, or the patient is treated and released, these records tend to go dormant with little
or no activity for long periods of time. Perhaps a few reports are run to show how many claims
were processed or a warranty claim is processed by the manufacturer, but this is often a tiny percentage
of the total processing volume and tends to occur on a more random data set.
Now think about most of the database users all trying to update records, add new records, delete
records, and report on the last month’s (or even week’s) data at once, and you can see that a small
handful of records is often used many times by many users at any given time. Which records are
being used changes as the data ages and new claims or orders are processed, but the fact remains
that with all of this emphasis on a small percentage of the data, collisions are virtually inevitable.
It is critical, therefore, that the DBMS be capable of ensuring that such collisions are handled so
that data loss does not occur. For exactly this reason, you use transactions.