MariaDB Crash Course - Ben Forta [79]
As explained in Chapter 21, “Creating and Manipulating Tables,” MariaDB supports the use of several underlying database engines. Not all engines support explicit management of transaction processing, as explained in this chapter. One of the most commonly used engines is MyISAM, which does not support explicit transaction management, while InnoDB and ARIA do. This is why the sample tables used in this book were created to use ARIA. If you need transaction processing functionality in your applications, be sure to use the correct engine type.
* * *
Transaction processing is used to maintain database integrity by ensuring that batches of MariaDB SQL operations execute completely or not at all.
As explained back in Chapter 15, “Joining Tables,” relational databases are designed so data is stored in multiple tables to facilitate easier data manipulation, management, and reuse. Without going into the hows and whys of relational database design, take it as a given that well-designed database schemas are relational to some degree.
The orders tables you’ve been using in prior chapters are a good example of this. Orders are stored in two tables: orders stores actual orders, and orderitems stores the individual items ordered. These two tables are related to each other using unique IDs called primary keys (as discussed in Chapter 1, “Understanding SQL”). These tables, in turn, are related to other tables containing customer and product information.
The process of adding an order to the system is as follows:
1. Check whether the customer is already in the database (present in the customers table). If not, add him or her.
2. Retrieve the customer’s ID.
3. Add a row to the orders table associating it with the customer ID.
4. Retrieve the new order ID assigned in the orders table.
5. Add one row to the orderitems table for each item ordered, associating it with the orders table by the retrieved ID (and with the products table by product ID).
Now imagine that some database failure (for example, out of disk space, security restrictions, table locks) prevents this entire sequence from completing. What would happen to your data?
Well, if the failure occurred after the customer was added and before the orders table was added, there is no real problem. It is perfectly valid to have customers without orders. When you run the sequence again, the inserted customer record will be retrieved and used. You can effectively pick up where you left off.
But what if the failure occurred after the orders row was added, but before the orderitems rows were added? Now you’d have an empty order sitting in your database.
Worse, what if the system failed during adding the orderitems rows? Now you’d end up with a partial order in your database, but you wouldn’t know it.
How do you solve this problem? That’s where transaction processing comes in. Transaction processing is a mechanism used to manage sets of SQL operations that must be executed in batches to ensure that databases never contain the results of partial operations. With transaction processing, you can ensure that sets of operations are not aborted mid-processing—they either execute in their entirety or not at all (unless explicitly instructed otherwise). If no error occurs, the entire set of statements is committed (written) to the database tables. If an error does occur, a rollback (undo) can occur to restore the database to a known and safe state.
So, looking at the same example, this is how the process would work:
1. Check whether the customer is already in the database; if not, add him or her.
2. Commit the customer information.
3. Retrieve the customer’s ID.
4. Add a row to the orders table.
5. If a failure occurs while adding the row to orders, roll back.
6. Retrieve the new order ID assigned in the orders table.
7. Add one row to the orderitems table for each item ordered.
8. If a failure occurs while adding rows to orderitems, roll back all the orderitems rows added and the orders row.
9. Commit the order information.
When working with transactions and transaction