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

Иерархическая модель
Иерархические структуры легко понять и использовать. Фактически впервые 
они были реализованы в базах данных в 1960-х годах благодаря простоте 
применения и нетребовательности к памяти. Конечно, в то время не было 
ни XML, ни JSON. Эти структуры отлично работают, пока все укладывается 
в одну иерархию. Но как только данные попадают в несколько иерархий, 
подход становится и сложным, и неэффективным.
Проиллюстрируем это на примерах из схемы 
postgres_air
, показанных 
на рис. 9.1. Для аэропорта список вылетающих рейсов представляет собой 
одну иерархию, а список прибывающих рейсов – другую. Посадочные тало-

---

Зачем использовать реляционную модель 

171
ны могут входить в ту же иерархию, что и вылетающие рейсы. В то же время 
они могут быть частью совершенно другой иерархии, которая начинается 
с бронирований. Обратите внимание, что пассажиры и перелеты не могут 
входить в одну и ту же иерархию без дублирования.
Аэропорт
Рейс
Пассажир
Аэропорт
Рейс
Бронирование
Рейс
Пассажир
Вылеты
Посадка
Прибытия
Рис. 9.1 

Примеры иерархий в схеме postgres_air
Первые иерархические базы данных (IMS/360) предоставляли несколько 
иерархических представлений данных клиентскому приложению, но внутри 
поддерживали более сложные структуры данных.
Лучшее из разных миров
PostgreSQL – не просто реляционная, а объектно-реляционная система. Это 
означает, что типы данных столбцов не обязательно являются скалярными. 
Столбцы могут хранить структурированные типы, включая массивы, состав-
ные типы или объекты, представленные в виде документов JSON или XML.
Ответственное использование этих функций обеспечивает все потенци-
альные преимущества нескольких альтернативных подходов в сочетании 
с более традиционными реляционными возможностями.
В данном случае слово «ответственное» является ключевым. Например, 
PostgreSQL допускает подход с множественной иерархией, упомянутый 
в предыдущем разделе. Мы можем создать иерархические представления для 
клиентского приложения поверх внутренней реляционной структуры в базе 
данных. Такой подход сочетает в себе лучшее из обоих миров: для эффек-
тивного извлечения данных используется вся мощь реляционных запросов, 
а приложение получает сложные объекты в удобном формате обмена дан-
ными. Более подробная информация об этом подходе приведена в главе 13.
Хотя в этой книге мы не рассматриваем распределенные системы, стоит 
упомянуть, что у PostgreSQL имеется огромный набор расширений (допол-
нительных библиотек, не входящих в базовый дистрибутив), которые под-
держивают распределенные запросы, включая запросы к СУБД, отличным 
от PostgreSQL. Эти расширения называются 
обертками
сторонних
данных

---

172

Проектирование имеет значение
(FDW, foreign data wrappers). Они предоставляют почти прозрачные способы 
доступа к данным, которые могут находиться в более чем 60 типах СУБД, как 
реляционных, так и нереляционных.