Часть проблем физического проектирования баз данных в большой степени зависит от особенностей используемого сервера баз данных. В частности, это относится к планированию размещения в дисковой памяти различных частей базы данных: таблиц, индексов, BLOB'ов, журналов и т.д. Соответствующие рекомендации обычно содержатся в руководстве администратора используемой системы.
Но можно, тем не менее, выделить некоторые общие соображения, которые осмысленны вне зависимости от деталей реализации сервера. Прежде всего это касается индексов. Понятно, что чем больше индексов существует над таблицами базы данных, тем более вероятным будет выполнение запросов по выборке данных и тем медленнее будут выполняться операции модификации базы данных.
В большинстве систем индекс создается автоматически для каждого определенного в таблице первичного, возможного и внешнего ключа. Здесь никуда не денешься: потребность в определении ключей следует из семантики предметной области, а для поддержания и использования ключей СУБД нуждается в соответствующих индексах. Но вот что касается дополнительных индексов, вводимых для целей более эффективного выполнения запросов, то с ними нужно быть очень аккуратным. Требуется тщательный предварительный анализ наиболее важного набора запросов (к сожалению далеко не всегда это возможно). Нужно также отдавать себе отчет в том, что создание нового индекса для большой заполненной таблицы - это серьезная дорогостоящая операция (как правило, СУБД выполняет сортировку строк таблицы в соответствии со значением ключевого атрибута).
Далее, хотя в языке SQL и в большинстве его реализаций допускается динамическое изменение реляционной схемы базы данных, не все такие изменения выполняются дешево и безопасно. Дешево и безопасно можно создать новую таблицу с набором индексов и добавить столбец к существующей заполненной таблице. Дорого и опасно уничтожается большая заполненная таблица или ее отдельный столбец. (Опасно в том смысле, что, как правило, соответствующие операции не журнализуются.)
Противоречия теории и практики
Достаточно часто абсолютно правильно спроектированная реляционная схема базы данных мешает эффективному выполнению транзакций в конкретной прикладной области при использовании конкретного сервера баз данных. Обычно это связано с особенностями синхронизации параллельно выполняемых транзакций.
Предположим, например, что для синхронизации используется механизм блокировки строк таблиц, и существует дополнительный оператор LOCK TABLE, позволяющий явно блокировать таблицу целиком. В базе данных содержится таблица с информацией о сотрудниках большой компании, каждый из которых приписан к отделу, включающему большое число сотрудников. В большинстве транзакций приложения работа происходит только с одним отделом, но из-за большого числа строк, относящихся к этому отделу, используется оператор LOCK TABLE (иначе таблицы синхронизатора могли бы переполниться). Тем самым, в других транзакциях нельзя будет изменить информацию о сотруднике, работающем совсем в другом отделе. Одно из возможных решений проблемы состоит в том, чтобы завести столько отдельных таблиц, сколько существует отделов. Это позволит приложению в целом работать более эффективно, хотя и не оправданно с точки зрения теории.
Второй пример. Опять же используется блокировка строк, и в базе данных находится широкая правильно спроектированная таблица, обладающая тем свойством, что небольшое число столбцов меняется, а основная их часть только читается. Тогда любая изменяющая таблицу транзакция заблокирует все читающие транзакции. Решение снова состоит в том, чтобы немного отойти от теории и разбить таблицу на две: изменяемую и только читаемую.
Денормализация для оптимизации
В этом подразделе мы только наметим тему обсуждения. Если еще раз внимательно посмотреть на шаги процесса построения хорошей нормализованной схемы реляционной базы данных, то можно заметить, что на каждом шаге нормализации порождаются потенциальные соединения отношений. Для некоторых приложений это несущественно, для других - критично. Известно, что если для выполнения запроса к базе данных требуется выполнить десять соединений, то ни один из современных серверов баз данных не обеспечивает умеренное время ответа.
Поэтому иногда приходится жертвовать идеями и работать с недостаточно нормализованной схемой БД. Конечно, при работе с такой схемой могут возникать аномалии изменений, но с ними можно бороться другими способами, например, с помощью триггеров.
