Противоречия теории и практики
Достаточно часто абсолютно правильно спроектированная реляционная схема базы данных мешает эффективному выполнению транзакций в конкретной прикладной области при использовании конкретного сервера баз данных. Обычно это связано с особенностями синхронизации параллельно выполняемых транзакций.
Предположим, например, что для синхронизации используется механизм блокировки строк таблиц, и существует дополнительный оператор LOCK TABLE, позволяющий явно блокировать таблицу целиком. В базе данных содержится таблица с информацией о сотрудниках большой компании, каждый из которых приписан к отделу, включающему большое число сотрудников. В большинстве транзакций приложения работа происходит только с одним отделом, но из-за большого числа строк, относящихся к этому отделу, используется оператор LOCK TABLE (иначе таблицы синхронизатора могли бы переполниться). Тем самым, в других транзакциях нельзя будет изменить информацию о сотруднике, работающем совсем в другом отделе. Одно из возможных решений проблемы состоит в том, чтобы завести столько отдельных таблиц, сколько существует отделов. Это позволит приложению в целом работать более эффективно, хотя и не оправданно с точки зрения теории.
Второй пример. Опять же используется блокировка строк, и в базе данных находится широкая правильно спроектированная таблица, обладающая тем свойством, что небольшое число столбцов меняется, а основная их часть только читается. Тогда любая изменяющая таблицу транзакция заблокирует все читающие транзакции. Решение снова состоит в том, чтобы немного отойти от теории и разбить таблицу на две: изменяемую и только читаемую.
