Joe Celko, Looking at VIEWs, Close Up
Первые стандарты SQL-86 ввели немного «стандартного языка»: слово, которое продолжает использоваться до сих пор. Это слово — «эффективно». «Эффективно» используется для описания конечного эффекта оператора. Мы не определяем реализацию. Мы определяем результат. Вы, вероятно, предположили бы, что так должны делать все стандарты для языков, но стандарты как для FORTRAN, так и для COBOL изначально определяли непрерывное хранение и другие подобные детали реализации. Насколько мне известно, мы были первыми, кто отошёл от этой модели в стандарте SQL.
Представления (VIEW) — это виртуальные таблицы, определяемые оператором SELECT, и они должны эффективно вести себя так, как если бы результат этого оператора был реальной физической базовой таблицей. Это означало, что в любом месте грамматики, где разрешена таблица, вы можете использовать представление. Для данных представлений не выделяется место до тех пор, пока они не будут вызваны, поэтому они экономичны с точки зрения ресурсов.
К сожалению, большинство продуктов SQL показывают представления и базовые таблицы отдельно в своих обозревателях объектов, как если бы они были принципиально разными. Я подозреваю, что причина в том, что текст запроса должен быть сохранён (по причинам, которые мы рассмотрим через минуту), и поэтому он помещается в другую часть информационной схемы. Вероятно, просто проще не объединять базовые таблицы и представления для отображения в инструменте.
Синтаксис VIEW в Standard SQL
CREATE VIEW <имя таблицы> [(<список столбцов представления>)]
AS <выражение запроса>
[WITH [<уровневая клауза>] CHECK OPTION]
<уровневая клауза> ::= CASCADED | LOCAL
<view column list> необязателен; когда он не указан, представление унаследует имена столбцов из запроса. Количество имён столбцов в <view column list> должно совпадать со степенью (количеством столбцов) выражения запроса. Если какие-либо два столбца в запросе имеют одинаковое имя столбца, вы должны указать <view column list>, чтобы разрешить неоднозначность. Одно и то же имя столбца не может быть указано более одного раза.
Опция <levels clause> в WITH CHECK OPTION не существовала в SQL-89 и не влияет на запросы, а только на операторы UPDATE, INSERT INTO и DELETE FROM. Мы подробно рассмотрим эту недооценённую возможность. Она связана с вложенными представлениями и тем, как они «разворачиваются» при событии в базе данных.
Продолжить чтение "Всматриваясь в ПРЕДСТАВЛЕНИЯ (VIEW)"
