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

Модель «сущность–атрибут–значение»
В модели 
сущность–атрибут–значение
(entity-attribute-value, EAV) значения 
являются скалярными (обычно текстовыми, чтобы представлять разные типы 
данных). В главе 6 говорилось, что в этой модели есть таблица с тремя столб-
цами: первый для идентификатора сущности, второй для идентификатора 
атрибута этой сущности, а третий – значение этого атрибута сущности. Это 
сделано во имя «гибкости», которая на самом деле означает неточные или 
неизвестные требования. Неудивительно, что такая гибкость достигается за 
счет производительности. В главе 6 была представлена таблица 
custom_field
. 
Мы отметили, что эта схема не является оптимальной, и показали возможное 
отрицательное влияние на производительность. Даже после применения ме-
тодов оптимизации для устранения многократного сканирования таблицы 
выполнение оставалось относительно медленным.
Помимо влияния на производительность, такая схема ограничивает 
управление качеством данных. В случае, представленном в главе 6, три поля 
содержат данные трех разных типов: 
passport_num
– число, 
passport_exp_date
– 
дата, а 
passport_country
– текстовое поле, которое должно содержать название 
существующей страны. Однако в таблице 
custom_field
все эти значения хра-
нятся в текстовом поле 
custom_field_value
, что делает невозможным строгую 
типизацию и не позволяет создавать ограничения ссылочной целостности.
Модель «ключ–значение»
Тип, используемый в модели «ключ–значение», хранит сложные объекты 
в одном поле, структура которого не видна базе данных. В этом случае от-
дельные атрибуты объекта гораздо сложнее извлечь, и движок базы данных 

---

170

Проектирование имеет значение
может, по сути, только возвращать один объект по первичному ключу. Все 
поля, кроме первичного ключа, даже могут быть упакованы в один объект 
JSON.
После того как PostgreSQL представил поддержку JSON в версии 9.2, этот 
подход стал очень популярным среди разработчиков баз данных и приложе-
ний. В версии 9.4 был представлен JSONB, и в каждой последующей версии 
следовали дальнейшие улучшения. Благодаря этой поддержке столбцы таб-
лицы, определенные как JSON, являются обычным делом. Например, таблицу 
пассажиров из схемы 
postgres_air
можно определить, как показано в лис-
тинге 9.5.
Листинг 9.5 

Таблица с JSON
CREATE TABLE passenger_json (
passenger_id int,
passenger_info json
);
Пример значения JSON для 
passenger_info
показан в лис тинге 9.6.
Листинг 9.6 

Пример значения JSON
{
"booking_ref": "8HNB12",
"passenger_no": "1",
"first_name": "MARIAM",
"last_name": "WARREN",
"update_ts": "2020-04-17T19:45:55.022782-05:00",
}
Да, предлагаемая схема выглядит универсальной и не требует каких-либо 
изменений DDL независимо от того, сколько новых элементов данных будет 
добавлено в будущем. Однако этой модели присущи те же проблемы, что 
и модели EAV. При таком подходе невозможно проверять типы скалярных 
значений и невозможно определить ограничения ссылочной целостности.
Инструменты и подходы для работы с полями JSON обсуждаются далее 
в данной главе.