|
Листинг 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
Правильное и неправильное использование суррогатных ключей
Do'stlaringiz bilan baham: |
