ON od.ProductID = p.ProductID WHERE CONVERT(varchar(12), о.OrderDate ,101) =

CONVERT(varchar(12),DATEADD(day,-1,GETDATE()),101)

К сожалению, все даты, которые хранятся в базе данных AdventureWorks, относятся к давно прошедшему времени, поэтому запрос к данному представлению врад ли возвратит какие-либо данные; в связи с этим введем дополнительную строку для проверки рассматриваемого представления. Вызовите один раз на вьшолнение следующий сценарий: USE AdventureWorks

DECLARE ©Ident int

INSERT INTO Sales.SalesOrderHeader

(CustomerlD,

OrderDate,

DueDate,

ContactID,

BillToAddressID,

ShipToAddressID,

ShipMethodID) VALUES

(1, DATEADD(day,-1,GETDATE0), GETDATE(), 1, 1, 1, 1) SELECT ©Ident = ©©IDENTITY

INSERT INTO Sales.SalesOrderDetail

(SalesOrderlD,

OrderQty,

ProductID,

SpecialOfferlD,

UnitPrice,

UnitPriceDiscount) VALUES

(©Ident, 4, 765, 1, 50, 0)

SELECT The OrderlD of the INSERTed row is + CONVERT(varchar(8),©Ident)

Безусловно, для опытных разработчиков основная часть содержимого этого сценария должна быть вполне понятной, что же касается тех, кто впервые сталкивается с подобной темой, то все применяемые здесь конструкции будут подробно описаны в главе, посвященной сценариям и пакетам. А на данный момент отметим, что этот сценарий позволяет ввести в базу данных AdventureWorks такие значения, выборка которых должна быть осуществлена с помощью представления. После вьшолнения указанного сценария в программе Management Studio должен появиться результат, который выглядит так:

(1 row(s) affected) (1 row(s) affected)

The OrderlD of the INSERTed row is 75132 (1 row(s) affected)

Следует учитывать, что некоторые из приведенных здесь сообщений появятся во вкладке Messages, только если программа Management Studio эксплуатируется в режиме отображения результатов в сетке. Results In Grid.

При выполнении этого примера на другом компьютере значение SalesOrderlD может изменрггься, но остальная часть результатов должна остаться в основном такой же.

Теперь выполним запрос применительно к рассматриваемому представлению, чтобы узнать, каковы будут результаты:

SELECT SalesOrderlD, OrderDate FROM YesterdaysCustomerOrders vw

Полученные результаты действительно показывают, что в базе данных появилась информация о заказе с номером 75132 за вчерашний день: SalesOrderlD OrderDate

75132 2006-03-12 15:28:52.903

(1 row{s) affected)

He следует предавать большого значения тому, что фактически полученшле дан- ные о номерах заказов, SalesOrderlD, будут отличаться от приведешгых в кго1ге. Дело в том, что эти номера присваиваются системой (поскольку SalesOrderlD - столбец едентификации) и зависят от того, сколько строк уже вставлено в таблицу. Иными словами, при выполнении данного примера читатели могут полу- чить другие номера заказов.

Использование представлений для внесения изменений в данные до ввода в действие триггеров instead of

Как уже было сказано, с точки зрения функциональных возможностей их использования представления почти полностью аналогичны таблицам (хотя, разумеется, для создания представлений применяются совсем другие конструкции по сравнению с таблицами). Но в этом разделе основное внимание уделено тому, в чем состоят функциональные различия между таблицами и представлениями.

Многие начинающие разработчики об этом не догадываются, но следует знать, что к представлениям могут успешно применяться операторы INSERT, UPDATE и DELETE. Тем не менее при использовании операций модификации данных с помощью представлений необходимо учитывать некоторые нюансы, описанные ниже.

Если оператор выборки, лежащий в основе представления, содержит операцию соединения, то в большинстве случаев с помощью этого представления невозможно вставлять или удалять данные, применяя оператор INSERT или DELETE, если при этом не используется триггер INSTEAD OF. В некоторых случаях оператор UPDATE может применяться без триггера INSTEAD OF (например, при условии, что обновляются только те столбцы, которые относятся к одной и той же таблице), но требуется некоторая дополнительная подготовка, так как в противном случае при выполнении операторов обновления могут вскоре возникнуть проблемы.

Если представление ссылается только на одну таблицу, то вставка данньгх с помощью оператора INSERT с использованием представления может осуществляться без применения триггера INSTEAD OF, при условии, что в представлении обеспечивается доступ ко всем обязательным (не допускающим неопределенных значений) столбцам таблицы или для этих столбцов заданы значения.

применяемые по умолчанию. Если же в таблице имеется столбец, который не определен в представлении и не имеет заданного по умолчанию значения, то при использовании триггера INSTEAD OF применение оператора INSERT допускается даже в случае представлений, относящихся к единственной таблице.

Предусмотрена возможность, хотя и в ограниченной степени, регламентировать, какие данные могут и не могут быть вставлены или обновлены в представлении.

Как показывает приведенное описание условий модификации данных с помощью представлений, во многих случаях невозможно обойтись без триггеров INSTEAD OF. Триггер INSTEAD OF - это особая, довольно сложная разновидность триггера, которая будет подробно рассматриваться в главе 13. Дело в том, что мы вьшуждены разбираться в нюансах применения триггеров, еще не обсудив саму эту тему достаточно подробно. Автор уже неоднократно указывал, что при описании проблематики, связанной с СУБД SQL Server, часто приходится сталкиваться со старой дилеммой курицы и яйца (что появилось раньше?). Автор обязан раскрыть тему триггеров INSTEAD OF, поскольку она имеет непосредственное отношение к представлениям, но на страницах этой книги нельзя переходить к описанию триггеров INSTEAD OF, не изложив все необходимые сведения о тех объектах, на которых они создаются (речь идет о таблицах и представлени51х).

Поэтому автор решил в этой главе раскрыть тематику представлений в том аспекте, в каком эти объекты применялись с самого начала, еще до введения таких конструкций, как триггеры INSTEAD OF. Но хотя при изучении настоящей главы читатель не будет знакомиться с конкретными сведениями о триггерах INSTEAD OF, он должен хорошо понимать, в чем состоит их назначение. Таким образом, ознакомившись в данной главе с кратким обзором триггеров INSTEAD OF, мы снова вернемся к этой теме и раскроем ее более подробно в главе 13.

Но самая главная особенность триггеров INSTEAD OF должна бить отмечена в данной гяаве. Это - триггеры особого рода, которые по существу вызываются на выполнение вместо (instead of, отсюда их название) того оператора, который вызвал запуск триггера. Благодаря такой организации работы после запуска триггера можно определить, какие действия уже были выполнены с помощью оператора, а затем непосредственно в коде триггера принять решения, касающиеся тюго, как разреш,ить любые возникшие конфликты или устранить другие проблемы, которые, возможно, проявились к этому моменту. Таким образом, триггеры INSTEAD OF являются очень мощными, но вместе с тем довольно сложными, поэтюму отложим их описание до одной из следующих глав.

Внесение изменений в данные с помощью представлений в условиях использования операций соединения

Если представление определено больше чем на одной таблице, то без использования триггера INSTEAD OF модификация данных с помощью представления становится затруднительной или даже вообще невозможной. Корпорацией Microsoft было принято решение запретить по умолчанию модификацию данньгх с помощью представлений, в которых используется несколько таблиц, поскольку при этом возникают некоторые неоднозначности при выборе способов реализации операций внесения изменений. Но разработчик может взять на себя обязанности по устранению проти-