Руководство по созданию эффективных запросов

Листинг 9.7 

Индексирование столбца JSON
CREATE INDEX passenger_j_booking_ref
ON passenger_json ((passenger_info->>'booking_ref'));
Он будет работать медленнее, чем индекс по исходной таблице 
passenger
, 
но лучше, чем последовательное сканирование. Однако для любого значения, 
которое должно быть числовым или содержать дату, потребуется то же пре-
образование, что и в предыдущем примере.
Это не означает, что ни одно из этих нереляционных решений не имеет 
права на жизнь.
Например, одна таблица, описывающая некоторые нормативные акты Ев-
росоюза, содержала около 500 столбцов. При смене правил, примерно раз 
в пять лет, в нее добавлялась одна строка. Замена этой таблицы вариацией 
модели «ключ–значение» (с парой дополнительных столбцов, характеризу-
ющих значение) пришлась по душе и разработчикам баз данных, и разработ-
чикам приложений. Благодаря размеру данных проблем с эффективностью 
не возникло.
Мы рекомендуем применять столбцы JSON только в тех случаях, когда 
данные используются как единый объект, например при хранении внешних 
документов, кредитных отчетов и т. п. Даже в этих случаях те атрибуты, ко-
торые будут применяться для поиска, рекомендуется по возможности раз-
ложить по отдельным столбцам и хранить в дополнение ко всему объекту.
н
ужна
 
ли
 
нормализаЦия
?
Во всей реляционной теории чаще всего неправильно используется термин 
«нормализация». Обычно все администраторы и разработчики баз данных, 
системные архитекторы и все остальные заявляют, что система должна быть 
«нормализована», но лишь немногие могут объяснить, что они хотят этим 
достичь, не говоря уже об определении нормализации.
Это не просто снобизм; нет никакой необходимости запоминать опре-
деление каждой нормальной формы всем, кто работает в области управ-
ления данными. Алгоритмы реляционной нормализации на практике ис-
пользуются нечасто. В этом смысле нормализация – это «мертвая» теория, 

---

174

Проектирование имеет значение
как латынь – мертвый язык. Тем не менее ученые все еще находят пользу 
в изучении латыни, а некоторые знания нормализации необходимы для ка-
чественного проектирования базы данных.
Неформально схема базы данных нормализована, если все значения столб-
цов зависят только от первичного ключа таблицы, а данные разбиты на не-
сколько таблиц, чтобы избежать повторений.
Один из способов создания нормализованной схемы – начать с построе-
ния модели «сущность–связь»: если сущности определены правильно, схе-
ма базы данных, созданная из этой модели, будет нормализована. Можно 
сказать, что модель «сущность–связь» неявно включает в себя обнаружение 
зависимостей. Если она не нормализована, обычно это означает, что какие-
то сущности отсутствуют.
Действительно ли важно нормализовать схему базы данных? Улучшает ли 
это производительность? Как обычно, все зависит от обстоятельств.
Повышение производительности 
не
является основной целью нормализа-
ции. Нормализация создает чистую логическую структуру и помогает обеспе-
чить целостность данных, особенно когда она поддерживается ограничения-
ми ссылочной целостности. Нормализация необходима по тем же причинам, 
что и реляционная модель: не столько для хранения данных, сколько для 
обеспечения целостности и возможности использовать язык реляционных 
запросов. Отображение между логической структурой и структурой хране-
ния не обязательно взаимно однозначно. В идеале для приложения должна 
быть предусмотрена чистая логическая структура, основанная на структуре 
хранения, оптимизированной для производительности.
С другой стороны, в мире есть много всего денормализованного, для чего 
нормализация не дает никаких преимуществ. Самый известный пример – 
почтовый адрес. Почтовый адрес США состоит из улицы с домом, города, 
почтового индекса и штата.
Адрес не является нормализованным. Это знают все, кто когда-либо от-
правлял посылки через киоски-автоматы USPS. Автоматическая проверка 
не позволит вам ввести почтовый индекс, не совпадающий с уже введенным 
адресом. Однако мы сомневаемся, что кто-то решит нормализовать адреса, 
хранящиеся в таблице базы данных.
Часто в поддержку денормализованной структуры данных приводится 
аргумент, что «соединения требуют времени» и поэтому денормализация 
необходима, чтобы запросы выполнялись быстрее. Для коротких запросов, 
когда они построены правильно, дополнительное время на соединения не-
значительно, как мы обсуждали в главе 5, и не следует жертвовать ради него 
точностью данных.
Во многих же случаях нормализация позволяет улучшить производитель-
ность, например когда нужно выбрать отдельные значения некоего атрибу-
та с высокой избирательностью или, в общем случае, любое подмножество 
столбцов с повторяющимися значениями в ненормализованной таблице. 
В схеме 
postgres_air
статус рейсов в таблице 
flight
указывается явно. Это 
означает, что для получения списка возможных статусов рейсов необходимо 
выполнить следующий запрос:
SELECT DISTINCT status FROM flight

---

Правильное и неправильное использование суррогатных ключей 
