An OLTP database has been designed to handle large numbers of statements that cause changes to the database. Basically, the INSERT, UPDATE, and DELETE statements all cause changes and behave very differently from the SELECT statement. OLTP databases have been designed with this in mind. Because these databases record changes, they are typically the main or master database, meaning that they are the repositories that hold the current data.

OLTP databases are typically designed to process change statements quickly. This is normally done by the careful planning of table structures. A simple way of viewing this is to consider a database table. This table can have fields for storing data, keys for looking up the data efficiently, indexes to other tables, triggers to respond to specific situations, and other table constructs. Each one of these constructs has a performance penalty. The design of OLTP databases is, therefore, a balance between using the minimum number of constructs on a table versus the desired behavior.

Let's consider a table that records the books in our inventory system. Each book might record the name, quantity, date published, and have references to author information, publishers, and other related tables. We could put an index on all columns and even add indexes for the data in related tables. The problem with this approach is that each index has to be stored and maintained for each statement that causes change. Database designers have to carefully plan and analyze databases in order to determine the optimal combination of adding and, just as importantly, not adding indexes and other constructs to tables.