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

г
иБкость
 
Против
 
эффективности
 
и
 
корректности
Частым аргументом в пользу гибкой схемы служит посыл «определение схе-
мы или структуры данных может поменяться», ведь добавление столбца – это 
команда DDL, а добавление строки (в модели «ключ–значение») – это просто 
добавление строки.
Действительно, реальные системы эволюционируют, и, чтобы адекватно 
отражать эти изменения, существующие структуры данных должны меняться. 
Это может повлечь за собой добавление или удаление некоторых атрибутов 
либо изменение типов данных или связей. Тем не менее неизбежность измене-
ний не обязывает использовать альтернативные модели, такие как хранилища 
документов или системы «ключ–значение». Стоимость внесения изменений 
в схему базы данных всегда необходимо сопоставлять с возможными проб-
лемами производительности и целостности данных этих гибких решений.
В предыдущем разделе говорилось о сложности создания ограничений 
целостности при нереляционном подходе. По некоторым причинам широко 
распространено мнение, что базы данных NoSQL «быстрее», чем реляцион-
ные базы данных. Это утверждение может быть верным в очень ограничен-
ном количестве сценариев, но в большинстве случаев ситуация обратная. 
Горизонтальное распределение может дать прирост производительности, 
но он уравновешивается стоимостью дополнительных шагов, необходимых 
для проверки целостности данных. Дополнительные потенциальные пробле-
мы с производительностью возникают из-за трудностей создания индексов 
в моделях EAV и «ключ–значение».
Например, в случае с таблицей 
custom_field
столбец 
passport_exp_date
дол-
жен быть датой, и ее часто сравнивают с другими датами, например с датой 
рейса, чтобы убедиться, что срок действия паспорта не истекает до даты 
вылета. Однако эта дата хранится в текстовом поле, а это означает, что ее 
нужно приводить к типу 
date
, чтобы корректно сравнивать значения. Более 
того, это приведение может выполняться только для строк, содержащих зна-
чения типа 
date
.
PostgreSQL имеет частичные индексы, поэтому можно создать индекс 
только для тех строк, которые содержат дату истечения срока действия пас-
порта. Однако их нельзя проиндексировать как дату, которую можно ис-
пользовать в качестве критерия поиска, поскольку индексы нельзя строить 
по изменчивым функциям:
CREATE INDEX custom_field_exp_date_to_date
ON custom_field (to_date(custom_field_value, 'MM-DD-YYYY'))
WHERE custom_field_name = 'passport_exp_date'

---

Нужна ли нормализация 

173
Это связано с тем, что все функции преобразования даты и времени являют-
ся изменчивыми, поскольку зависят от настроек текущего сеанса. Чтобы функ-
цию преобразования можно было использовать в индексе, придется написать 
собственную. В главе 10 рассказывается о создании пользовательских функций. 
Эта функция должна будет обрабатывать исключения, и поэтому значение, 
ошибочно добавленное в неправильном формате, не будет проиндексировано. 
Кроме того, сам поиск будет значительно медленнее, чем с полем 
date
.
Что насчет упаковки всех атрибутов в столбец JSON? Возникают анало-
гичные проблемы с индексацией. По столбцу JSON можно создать индекс; 
например, для таблицы 
passenger_json
из лис тинга 9.5 можно создать индекс 
по 
booking_ref
, как показано в лис тинге 9.7.