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

Примечание
Здесь показан лишь один из многих способов создания объекта с вло-
женной структурой. В следующих главах мы представим другие способы, которые могут 
оказаться более полезными в иных ситуациях.
А теперь плохие новости. Мы приложили столько усилий, чтобы создать 
эту функцию, но результат ее выполнения, показанный на рис. 11.4, несколь-
ко разочаровывает:
SELECT * FROM booking_leg_select (17564910)
Рис. 11.4 

Возвращенный сложный объект с вложенной структурой
Результат выглядит так, как мы хотели, но есть одна важная деталь. Для 
скалярных элементов PostgreSQL сохраняет имена (как если бы мы выбирали 
их из таблицы), но структура элементов, которые сами являются сложными 
объектами, не раскрывается. Обратите внимание, что внутри PostgreSQL 
по-прежнему сохраняет представление о структуре вложенного типа, но не 
передает ее на верхний уровень.
Почему это плохо? В главе 10 были рассмотрены подводные камни объект-
но-реляционного отображения, и на рис. 10.4 была дана схема возможного 
решения. На тот момент мы не обсуждали детали реализации, но с функция-
ми, которые могут возвращать сложные типы, цель кажется достижимой. 
Однако возвращаемое функцией значение бесполезно для приложения, если 
оно не может определить ни имя элемента, ни его тип.
Решение приводится в главе 13, но пока давайте сосредоточимся на функ-
циях, возвращающих записи без вложенной структуры.

---

Управление данными с помощью функций 

213
ф
ункЦии
 
и
 
зависимости
 
тиПов
В главе 7 упоминаются зависимости в контексте обычных и материализо-
ванных представлений. Определение материализованных представлений 
нельзя изменить без предварительного удаления объекта, а обычные пред-
ставления придется удалить, если изменяется набор столбцов. Это означает, 
что в таких случаях все зависимые объекты должны быть удалены и созданы 
заново. Если эти зависимые объекты, в свою очередь, используются в дру-
гих представлениях или материализованных представлениях, их зависимые 
объекты также должны быть удалены.
Это может привести к очень нежелательным последствиям. Мы наблюда-
ли ситуации в промышленных системах, когда одно изменение приводило 
к удалению более 60 зависимых объектов, которые приходилось создавать 
заново в определенном порядке.
К счастью, у нас нет такой проблемы с функциями. Поскольку инструкции 
SQL в теле функции не разбираются при создании функции, то нет и зависи-
мостей от таблиц, представлений, материализованных представлений или 
других функций и хранимых процедур, которые используются в теле функ-
ции. По этой причине функции нужно пересоздавать только тогда, когда это 
действительно необходимо, а не просто из-за каскадного удаления.
Однако функции создают новый тип зависимостей: функции зависят от 
типов возвращаемых значений, включая пользовательские типы. Как и ма-
териализованные представления, пользовательские типы данных нельзя 
изменить без предварительного удаления. Чтобы удалить тип, придется уда-
лить и все другие пользовательские типы, которые включают его как элемент, 
и все функции, которые зависят от того типа. Это может показаться еще 
более серь езной проблемой, но на самом деле это полезное свойство. Если 
пользовательский тип изменен, некоторые его элементы, скорее всего, были 
добавлены, удалены или изменены. А это означает, что запросы, возвраща-
ющие данный тип записи, должны быть пересмотрены, поэтому функции 
следует удалить.
Кроме того, в отличие от создания материализованного представления, 
которое может занять некоторое время, создание функции происходит прак-
тически мгновенно.