###
  • Интернет
  • Программы
  • Игры
  • Проблемы
  • Windows
  • Социальные сети
  • Android
  • Ios

    • Ms sql хранимая процедура message описание. Что лучше: специальные запросы или хранимые процедуры? Создание, изменение и удаление хранимых процедур

    30.10.2019 Проблемы

    Определяется понятие хранимых процедур. Приводятся примеры создания, изменения и использования хранимых процедур с параметрами. Дается определение входных и выходных параметров. Приводятся примеры создания и вызова хранимых процедур.

    Понятие хранимой процедуры

    Хранимые процедуры представляют собой группы связанных между собой операторов SQL, применение которых делает работу программиста более легкой и гибкой, поскольку выполнить хранимую процедуру часто оказывается гораздо проще, чем последовательность отдельных операторов SQL. Хранимые процедуры представляют собой набор команд, состоящий из одного или нескольких операторов SQL или функций и сохраняемый в базе данных в откомпилированном виде. Выполнение в базе данных хранимых процедур вместо отдельных операторов SQL дает пользователю следующие преимущества:

    • необходимые операторы уже содержатся в базе данных;
    • все они прошли этап синтаксического анализа и находятся в исполняемом формате; перед выполнением хранимой процедуры SQL Server генерирует для нее план исполнения , выполняет ее оптимизацию и компиляцию;
    • хранимые процедуры поддерживают модульное программирование , так как позволяют разбивать большие задачи на самостоятельные, более мелкие и удобные в управлении части;
    • хранимые процедуры могут вызывать другие хранимые процедуры и функции;
    • хранимые процедуры могут быть вызваны из прикладных программ других типов;
    • как правило, хранимые процедуры выполняются быстрее, чем последовательность отдельных операторов;
    • хранимые процедуры проще использовать: они могут состоять из десятков и сотен команд, но для их запуска достаточно указать всего лишь имя нужной хранимой процедуры . Это позволяет уменьшить размер запроса, посылаемого от клиента на сервер, а значит, и нагрузку на сеть.

    Хранение процедур в том же месте, где они исполняются, обеспечивает уменьшение объема передаваемых по сети данных и повышает общую производительность системы. Применение хранимых процедур упрощает сопровождение программных комплексов и внесение изменений в них. Обычно все ограничения целостности в виде правил и алгоритмов обработки данных реализуются на сервере баз данных и доступны конечному приложению в виде набора хранимых процедур , которые и представляют интерфейс обработки данных. Для обеспечения целостности данных, а также в целях безопасности, приложение обычно не получает прямого доступа к данным – вся работа с ними ведется путем вызова тех или иных хранимых процедур .

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

    Хранимые процедуры существуют независимо от таблиц или каких-либо других объектов баз данных. Они вызываются клиентской программой, другой хранимой процедурой или триггером. Разработчик может управлять правами доступа к хранимой процедуре , разрешая или запрещая ее выполнение . Изменять код хранимой процедуры разрешается только ее владельцу или члену фиксированной роли базы данных. При необходимости можно передать права владения ею от одного пользователя к другому.

    Хранимые процедуры в среде MS SQL Server

    При работе с SQL Server пользователи могут создавать собственные процедуры, реализующие те или иные действия. Хранимые процедуры являются полноценными объектами базы данных, а потому каждая из них хранится в конкретной базе данных. Непосредственный вызов хранимой процедуры возможен, только если он осуществляется в контексте той базы данных, где находится процедура.

    Типы хранимых процедур

    В SQL Server имеется несколько типов хранимых процедур .

    • Системные хранимые процедуры предназначены для выполнения различных административных действий. Практически все действия по администрированию сервера выполняются с их помощью. Можно сказать, что системные хранимые процедуры являются интерфейсом, обеспечивающим работу с системными таблицами, которая, в конечном счете, сводится к изменению, добавлению, удалению и выборке данных из системных таблиц как пользовательских, так и системных баз данных. Системные хранимые процедуры имеют префикс sp_ , хранятся в системной базе данных и могут быть вызваны в контексте любой другой базы данных.
    • Пользовательские хранимые процедуры реализуют те или иные действия. Хранимые процедуры – полноценный объект базы данных. Вследствие этого каждая хранимая процедура располагается в конкретной базе данных, где и выполняется.
    • Временные хранимые процедуры существуют лишь некоторое время, после чего автоматически уничтожаются сервером. Они делятся на локальные и глобальные. Локальные временные хранимые процедуры могут быть вызваны только из того соединения, в котором созданы. При создании такой процедуры ей необходимо дать имя, начинающееся с одного символа # . Как и все временные объекты, хранимые процедуры этого типа автоматически удаляются при отключении пользователя, перезапуске или остановке сервера. Глобальные временные хранимые процедуры доступны для любых соединений сервера, на котором имеется такая же процедура. Для ее определения достаточно дать ей имя, начинающееся с символов ## . Удаляются эти процедуры при перезапуске или остановке сервера, а также при закрытии соединения, в контексте которого они были созданы.

    Создание, изменение и удаление хранимых процедур

    Создание хранимой процедуры предполагает решение следующих задач:

    • определение типа создаваемой хранимой процедуры : временная или пользовательская. Кроме этого, можно создать свою собственную системную хранимую процедуру , назначив ей имя с префиксом sp_ и поместив ее в системную базу данных. Такая процедура будет доступна в контексте любой базы данных локального сервера;
    • планирование прав доступа. При создании хранимой процедуры следует учитывать, что она будет иметь те же права доступа к объектам базы данных, что и создавший ее пользователь;
    • определение параметров хранимой процедуры . Подобно процедурам, входящим в состав большинства языков программирования, хранимые процедуры могут обладать входными и выходными параметрами ;
    • разработка кода хранимой процедуры . Код процедуры может содержать последовательность любых команд SQL, включая вызов других хранимых процедур .

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

    <определение_процедуры>::= {CREATE | ALTER } PROC имя_процедуры [;номер] [{@имя_параметра тип_данных } [=default] ][,...n] AS sql_оператор [...n]

    Рассмотрим параметры данной команды.

    Используя префиксы sp_ , # , ## , создаваемую процедуру можно определить в качестве системной или временной. Как видно из синтаксиса команды, не допускается указывать имя владельца, которому будет принадлежать создаваемая процедура, а также имя базы данных, где она должна быть размещена. Таким образом, чтобы разместить создаваемую хранимую процедуру в конкретной базе данных, необходимо выполнить команду CREATE PROCEDURE в контексте этой базы данных. При обращении из тела хранимой процедуры к объектам той же базы данных можно использовать укороченные имена, т. е. без указания имени базы данных. Когда же требуется обратиться к объектам, расположенным в других базах данных, указание имени базы данных обязательно.

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

    Для передачи входных и выходных данных в создаваемой хранимой процедуре могут использоваться параметры , имена которых, как и имена локальных переменных, должны начинаться с символа @ . В одной хранимой процедуре можно задать множество параметров , разделенных запятыми. В теле процедуры не должны применяться локальные переменные, чьи имена совпадают с именами параметров этой процедуры.

    Для определения типа данных, который будет иметь соответствующий параметр хранимой процедуры , годятся любые типы данных SQL, включая определенные пользователем. Однако тип данных CURSOR может быть использован только как выходной параметр хранимой процедуры , т.е. с указанием ключевого слова OUTPUT .

    Наличие ключевого слова OUTPUT означает, что соответствующий параметр предназначен для возвращения данных из хранимой процедуры . Однако это вовсе не означает, что параметр не подходит для передачи значений в хранимую процедуру . Указание ключевого слова OUTPUT предписывает серверу при выходе из хранимой процедуры присвоить текущее значение параметра локальной переменной, которая была указана при вызове процедуры в качестве значения параметра . Отметим, что при указании ключевого слова OUTPUT значение соответствующего параметра при вызове процедуры может быть задано только с помощью локальной переменной. Не разрешается использование любых выражений или констант, допустимое для обычных параметров .

    Ключевое слово VARYING применяется совместно с параметром OUTPUT , имеющим тип CURSOR . Оно определяет, что выходным параметром будет результирующее множество.

    Ключевое слово DEFAULT представляет собой значение, которое будет принимать соответствующий параметр по умолчанию . Таким образом, при вызове процедуры можно не указывать явно значение соответствующего параметра .

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

    Параметр FOR REPLICATION востребован при репликации данных и включении создаваемой хранимой процедуры в качестве статьи в публикацию.

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

    Ключевое слово AS размещается в начале собственно тела хранимой процедуры , т.е. набора команд SQL, с помощью которых и будет реализовываться то или иное действие. В теле процедуры могут применяться практически все команды SQL, объявляться транзакции, устанавливаться блокировки и вызываться другие хранимые процедуры . Выход из хранимой процедуры можно осуществить посредством команды RETURN .

    Удаление хранимой процедуры осуществляется командой:

    DROP PROCEDURE {имя_процедуры} [,...n]

    Выполнение хранимой процедуры

    Для выполнения хранимой процедуры используется команда:

    [[ EXEC [ UTE] имя_процедуры [;номер] [[@имя_параметра=]{значение | @имя_переменной} |][,...n]

    Если вызов хранимой процедуры не является единственной командой в пакете, то присутствие команды EXECUTE обязательно. Более того, эта команда требуется для вызова процедуры из тела другой процедуры или триггера.

    Использование ключевого слова OUTPUT при вызове процедуры разрешается только для параметров , которые были объявлены при создании процедуры с ключевым словом OUTPUT .

    Когда же при вызове процедуры для параметра указывается ключевое слово DEFAULT , то будет использовано значение по умолчанию . Естественно, указанное слово DEFAULT разрешается только для тех параметров , для которых определено значение по умолчанию .

    Из синтаксиса команды EXECUTE видно, что имена параметров могут быть опущены при вызове процедуры. Однако в этом случае пользователь должен указывать значения для параметров в том же порядке, в каком они перечислялись при создании процедуры . Присвоить параметру значение по умолчанию , просто пропустив его при перечислении нельзя. Если же требуется опустить параметры , для которых определено значение по умолчанию , достаточно явного указания имен параметров при вызове хранимой процедуры . Более того, таким способом можно перечислять параметры и их значения в произвольном порядке.

    Отметим, что при вызове процедуры указываются либо имена параметров со значениями, либо только значения без имени параметра . Их комбинирование не допускается.

    Пример 12.1. Процедура без параметров . Разработать процедуру для получения названий и стоимости товаров, приобретенных Ивановым.

    CREATE PROC my_proc1 AS SELECT Товар.Название, Товар.Цена*Сделка.Количество AS Стоимость, Клиент.Фамилия FROM Клиент INNER JOIN (Товар INNER JOIN Сделка ON Товар.КодТовара=Сделка.КодТовара) ON Клиент.КодКлиента=Сделка.КодКлиента WHERE Клиент.Фамилия=’Иванов’ Пример 12.1. Процедура для получения названий и стоимости товаров, приобретенных Ивановым.

    Для обращения к процедуре можно использовать команды:

    EXEC my_proc1 или my_proc1

    Процедура возвращает набор данных.

    Пример 12.2. Процедура без параметров . Создать процедуру для уменьшения цены товара первого сорта на 10%.

    Для обращения к процедуре можно использовать команды:

    EXEC my_proc2 или my_proc2

    Процедура не возвращает никаких данных.

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

    CREATE PROC my_proc3 @k VARCHAR(20) AS SELECT Товар.Название, Товар.Цена*Сделка.Количество AS Стоимость, Клиент.Фамилия FROM Клиент INNER JOIN (Товар INNER JOIN Сделка ON Товар.КодТовара=Сделка.КодТовара) ON Клиент.КодКлиента=Сделка.КодКлиента WHERE Клиент.Фамилия=@k Пример 12.3. Процедура для получения названий и стоимости товаров, которые приобрел заданный клиент.

    Для обращения к процедуре можно использовать команды:

    EXEC my_proc3 "Иванов" или my_proc3 @k="Иванов"

    Пример 12.4. . Создать процедуру для уменьшения цены товара заданного типа в соответствии с указанным %.

    Для обращения к процедуре можно использовать команды:

    EXEC my_proc4 "Вафли",0.05 или EXEC my_proc4 @t="Вафли", @p=0.05

    Пример 12.5. Процедура с входными параметрами и значениями по умолчанию. Создать процедуру для уменьшения цены товара заданного типа в соответствии с указанным %.

    CREATE PROC my_proc5 @t VARCHAR(20)=’Конфеты`, @p FLOAT=0.1 AS UPDATE Товар SET Цена=Цена*(1-@p) WHERE Тип=@t Пример 12.5. Процедура с входными параметрами и значениями по умолчанию. Создать процедуру для уменьшения цены товара заданного типа в соответствии с указанным %.

    Для обращения к процедуре можно использовать команды:

    EXEC my_proc5 "Вафли",0.05 или EXEC my_proc5 @t="Вафли", @p=0.05 или EXEC my_proc5 @p=0.05

    В этом случае уменьшается цена конфет (значение типа не указано при вызове процедуры и берется по умолчанию).

    В последнем случае оба параметра (и тип, и проценты) не указаны при вызове процедуры, их значения берутся по умолчанию.

    Пример 12.6. Процедура с входными и выходными параметрами . Создать процедуру для определения общей стоимости товаров, проданных за конкретный месяц.

    CREATE PROC my_proc6 @m INT, @s FLOAT OUTPUT AS SELECT @s=Sum(Товар.Цена*Сделка.Количество) FROM Товар INNER JOIN Сделка ON Товар.КодТовара=Сделка.КодТовара GROUP BY Month(Сделка.Дата) HAVING Month(Сделка.Дата)=@m Пример 12.6. Процедура с входными и выходными параметрами. Создать процедуру для определения общей стоимости товаров, проданных за конкретный месяц.

    Для обращения к процедуре можно использовать команды:

    DECLARE @st FLOAT EXEC my_proc6 1,@st OUTPUT SELECT @st

    Этот блок команд позволяет определить стоимость товаров, проданных в январе (входной параметр месяц указан равным 1).

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

    Сначала разработаем процедуру для определения фирмы, где работает сотрудник.

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

    Затем создадим процедуру, подсчитывающую общее количество товара, который закуплен интересующей нас фирмой.

    CREATE PROC my_proc8 @fam VARCHAR(20), @kol INT OUTPUT AS DECLARE @firm VARCHAR(20) EXEC my_proc7 @fam,@firm OUTPUT SELECT @kol=Sum(Сделка.Количество) FROM Клиент INNER JOIN Сделка ON Клиент.КодКлиента=Сделка.КодКлиента GROUP BY Клиент.Фирма HAVING Клиент.Фирма=@firm Пример 12.7. Создание процедуры для определения общего количества товаров, приобретенных фирмой, в которой работает заданный сотрудник.

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

    DECLARE @k INT EXEC my_proc8 ‘Иванов’,@k OUTPUT SELECT @k

    22 ответов

    В моем опыте написания в основном приложений WinForms Client/Server это простые выводы, к которым я пришел:

    Использовать хранимые процедуры:

    • Для любой сложной работы с данными. Если вы собираетесь делать что-то действительно требующее таблиц курсора или temp, это, как правило, самый быстрый способ сделать это в SQL Server.
    • Если вам нужно заблокировать доступ к данным. Если вы не предоставляете доступ к таблице пользователям (или роли или чему-либо еще), вы можете быть уверены, что единственный способ взаимодействия с данными - через создаваемый вами СП.

    Использовать специальные запросы:

    • Для CRUD, когда вам не нужно ограничивать доступ к данным (или делаете это по-другому).
    • Для простых поисков. Создание SP для множества критериев поиска - это боль и сложность в обслуживании. Если вы можете создать достаточно быстрый поисковый запрос, используйте это.

    В большинстве моих приложений я использовал как SP, так и ad-hoc sql, хотя я считаю, что я использую SP все меньше и меньше, поскольку они в конечном итоге являются кодом, как С#, только сложнее контролировать, тестировать и поддерживать. Я бы рекомендовал использовать ad-hoc sql, если вы не можете найти конкретную причину.

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

    Встраивая запросы в ваше приложение, вы тесно связываете себя с вашей моделью данных.

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

    Я думаю, что это основной конфликт между людьми, которые должны поддерживать базу данных и людей, которые разрабатывают пользовательские интерфейсы.

    Как человек с данными, я бы не стал рассматривать работу с базой данных, к которой обращаются через adhoc-запросы, потому что их трудно эффективно настраивать или управлять. Как я могу узнать, что повлияет на изменение схемы? Кроме того, я не думаю, что пользователям следует предоставлять прямой доступ к таблицам базы данных по соображениям безопасности (и я имею в виду не только атаки SQL-инъекций, но также и потому, что это базовый внутренний элемент управления, который не допускает прямых прав и требует от всех пользователей используйте только procs, предназначенные для приложения, чтобы предотвратить возможное мошенничество. Любая финансовая система, которая позволяет напрямую вставлять, обновлять или удалять права на таблицы, имеет огромный риск для мошенничества. Это плохо.).

    Базы данных не являются объектно-ориентированными, а код, который кажется хорошим из объектно-ориентированной точки зрения, может быть крайне плохим с точки зрения базы данных.

    Наши разработчики сообщают нам, что они рады, что весь наш доступ к базам данных осуществляется через procs, потому что он значительно ускоряет исправление ошибки, зависящей от данных, а затем просто запускает proc в рабочей среде, а не создает новую ветвь кода и перекомпилировать и перезагрузить в производство. Мы требуем, чтобы все наши процессы были в подрывной деятельности, поэтому контроль источника не является проблемой вообще. Если он не находится в Subversion, он будет периодически удаляться dbas, поэтому нет никакого сопротивления использованию Source Control.

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

    Я не понимаю эту проблему с исходным кодом на хранимой процедуре. Вы определенно можете их контролировать, если только вы немного дисциплинированы.

    Всегда начинайте с файла.sql, который является источником хранимой процедуры. Поместите его в управление версиями после того, как вы написали свой код. В следующий раз, когда вы захотите отредактировать свою хранимую процедуру, вы получите ее из своего исходного элемента управления, чем ваша база данных. Если вы последуете этому, у вас будет такой же хороший источник управления, как и ваш код.

    Я хотел бы процитировать Tom Kyte от Oracle здесь... Вот его правило о том, где писать код... хотя и немного несвязанный, но хорошо знаю, я думаю.

    В нашем приложении есть слой кода, который предоставляет содержимое запроса (а иногда и вызов хранимой процедуры). Это позволяет нам:

    • легко получить все запросы при управлении версиями
    • чтобы сделать все изменения для каждого запроса для разных серверов баз данных
    • исключает повторение одного и того же кода запроса через наш код

    Контроль доступа реализуется в среднем слое, а не в базе данных, поэтому нам не нужны хранимые процедуры. Это в некотором роде средняя дорога между специальными запросами и хранимыми процедурами.

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

    Аргумент, что хранимые процедуры более эффективны, больше не содержит воды. текст ссылки

    Выполнение google для хранимой процедуры vs Dynamic Query покажет достойные аргументы в любом случае и, вероятно, лучше для вас принять ваше собственное решение...

    Некоторые вещи, о которых нужно подумать: Кому нужны хранимые процедуры, Anyways?

    Ясно, что это вопрос ваших собственных потребностей и предпочтений, но очень важно подумать о том, что при использовании специальных запросов в среде, ориентированной на общественность, есть безопасность. Всегда производите их параметризацию и следите за типичными уязвимостями, такими как SQL-инъекции .

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

    Я использую ad-hoc для запросов, которые динамически генерируются на основе пользовательского ввода.

    Procs по причинам, упомянутым другими, а также проще настроить proc с помощью профилировщика или частей proc. Таким образом, вам не нужно рассказывать кому-либо о запуске своего приложения, чтобы узнать, что отправляется на сервер SQL

    Если вы используете ad-hoc-запросы, убедитесь, что они параметризированы

    Параметрированный SQL или SPROC... не имеет значения с точки зрения производительности... вы можете запросить оптимизацию одного из них.

    Для меня последнее оставшееся преимущество SPROC заключается в том, что я могу исключить много прав на управление правами SQL, только предоставляя свои права на вход для выполнения sprocs... если вы используете Parametized SQL, логин, связанный с вашей строкой подключения, имеет намного больше прав (запись любого вида оператора выбора на одну из таблиц, к которым у них есть доступ, например).

    Я по-прежнему предпочитаю параметризованный SQL, хотя...

    Аргумент производительности sproc является спорным - 3 верхних RDBM используют кэширование плана запросов и некоторое время. Его документально подтвердили... Или еще 1995 год?

    Однако встраивание SQL в ваше приложение также является ужасным дизайном - обслуживание кода, по-видимому, является недостающей концепцией для многих.

    Если приложение может начинаться с нуля с помощью ORM (приложения с зеленым полем далеки от нескольких!), это отличный выбор, поскольку модель вашего класса управляет вашей моделью БД и экономит время.

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

    Этот гибридный подход облегчает управление разработчиками (возможно, мы являемся меньшинством, поскольку моя команда достаточно ярка, чтобы читать план запроса), а развертывание - это простая проверка из SVN. Кроме того, он упрощает коммутацию RDBM - просто замените файл ресурсов SQL (не так просто, как инструмент ORM, конечно, но это работает с устаревшими системами или не поддерживаемой базой данных)

    Мой опыт состоит в том, что 90% запросов и/или хранимых процедур вообще не должны записываться (по крайней мере, вручную).

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

    Я предпочитаю хранить все данные доступ в коде программы, в котором уровень доступа к данным выполняет прямые SQL-запросы. С другой стороны, логика управления , которую я поместил в базу данных в виде триггеров, хранимых процедур, пользовательских функций и еще чего-то. Примером того, что я считаю достойным базы данных, является генерация данных - предположим, что у нашего клиента есть имя FirstName и LastName. Теперь для пользовательского интерфейса требуется DisplayName, которое выводится из некоторой нетривиальной логики. Для этого поколения я создаю хранимую процедуру, которая затем запускается триггером всякий раз, когда обновляется строка (или другие исходные данные).

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

    Когда следует использовать хранимые процедуры и когда я должен использовать представления в SQL Server?

    Разрешения позволяют создавать динамические запросы, где мы можем передавать параметры?

    Какой из них самый быстрый, и на каком основании он быстрее, чем другой?

    Просмотры или хранимые процедуры постоянно сохраняют память?

    Что это значит, если кто-то скажет, что представления создают виртуальную таблицу, а процедуры создают таблицу материалов?

    Пожалуйста, дайте мне знать о более точках, если они есть.

    Solutions Collecting From Web of "В чем разница между хранимой процедурой и представлением?"

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

    Хранимая процедура использует параметры для выполнения функции … будь то обновление и вставка данных или возврат отдельных значений или наборов данных.

    Создание представлений и хранимых процедур – содержит некоторую информацию от Microsoft о том, когда и почему использовать их.

    Скажем, у меня есть две таблицы:

    tbl_user Столбцы: .user_id, .user_name, .user_pw

    tbl_profile Столбцы: .profile_id, .user_id .profile_description

    Поэтому, если я нахожусь в запросе из этих таблиц ALOT … вместо того, чтобы делать соединение в КАЖДОЙ peice sql, я бы определил вид, например:

    CREATE View vw_user_profile AS Select A.user_id, B.profile_description FROM tbl_user A left join tbl_profile B on A.user_id = b.user_id GO

    Поэтому в будущем, если я хочу запросить profile_description по идентификатору пользователя … все, что мне нужно сделать, это

    SELECT profile_description FROM vw_user_profile WHERE user_id = @ID

    Этот код можно использовать в хранимой процедуре, например:

    Create procedure dbo.getDesc @ID int AS begin SELECT profile_description FROM vw_user_profile WHERE user_id = @ID END GO

    Поэтому позже я могу позвонить

    Dbo.getDesc 25

    и я получу описание для идентификатора пользователя 25, где 25 – ваш параметр.

    Очевидно, что МНОГО больше, но это всего лишь основная идея.

    Сначала вам нужно понять, что оба – разные вещи. Хранимые процедуры лучше всего использовать для операторов INSERT-UPDATE-DELETE. и Представления используются для операторов SELECT. и вы должны использовать оба.

    В представлениях вы не можете изменять данные.

    Просмотры: Это виртуальная таблица, состоящая из одной или нескольких строк и столбцов из разных реальных таблиц базы данных. Это шаблон строк и столбцов нескольких таблиц. Вы не можете передавать какие-либо параметры здесь.

    Хранимые процедуры: они представляют собой набор предварительно выполненных SQL-заявлений, в которых вы можете отправлять параметры в качестве входных данных и получать выходные данные.

    Представления могут использоваться в Хранимой процедуре, но Хранимая процедура не может использоваться в Views …!

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

      Представления являются статическими. Подумайте о них как о новых таблицах с определенным макетом, а данные в них создаются «на лету», используя запрос, с которым вы его создали. Как и в любой таблице SQL, вы можете сортировать и фильтровать ее с помощью WHERE , GROUP BY и ORDER BY .

      Это зависит от того, что вы делаете.

      Это зависит от базы данных. Простые представления просто запускают запрос и фильтруют результат. Но такие базы данных, как Oracle, позволяют создать «материализованное» представление, которое в основном представляет собой таблицу, которая автоматически обновляется при изменении базовых данных вида.

      Материализованное представление позволяет создавать индексы в столбцах представления (особенно на вычисленных столбцах, которые не существуют нигде в базе данных).

      Я не понимаю, о чем вы говорите.

    Основное различие заключается в том, что когда вы запрашиваете представление, это определение вставляется в ваш запрос. Процедура также может давать результаты запроса, но она скомпилирована и так быстро. Другим вариантом являются индексированные представления.

    SQL View – это виртуальная таблица, основанная на запросе SQL SELECT. Представление ссылается на одну или несколько существующих таблиц базы данных или другие представления. Это мгновенный снимок базы данных, тогда как хранимая процедура представляет собой группу операторов Transact-SQL, составленную в единый план выполнения.

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

    Представление быстрее, поскольку оно отображает данные из таблиц, на которые ссылается, тогда как процедура хранилища выполняет sql-инструкции.

    Проверьте эту статью: Просмотр против хранимых процедур. Именно то, что вы ищете

    @Patrick правильно с тем, что он сказал, но, чтобы ответить на ваши другие вопросы, View создаст себя в памяти, и в зависимости от типа Joins, Data и если будет сделано какое-либо агрегирование, это может быть довольно голодный вид.

    Хранимые процедуры выполняют всю свою обработку либо с использованием Temp Hash Table, например, # tmpTable1, либо в памяти с помощью @ tmpTable1. В зависимости от того, что вы хотите сказать.

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

    Очевидно, большую часть времени таблицы памяти быстрее, если вы не извлекаете много данных.

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

    CREATE View vw_user_profile AS Select A.user_id, B.profile_description FROM tbl_user A left join tbl_profile B on A.user_id = b.user_id

    Я могу обновить данные … в качестве примера я могу сделать любой из этих …

    Update vw_user_profile Set profile_description="Manager" where user_id=4

    Update tbl_profile Set profile_description="Manager" where user_id=4

    Вы не можете ВСТАВИТЬ в это представление, так как не все поля во всей таблице присутствуют, и я предполагаю, что PROFILE_ID является первичным ключом и не может быть NULL. Однако иногда вы можете вставить INSERT в представление …

    Я создал представление для существующей таблицы, используя …

    Create View Junk as SELECT * from

    Insert into junk (Code,name) values ("glyn","Glyn Roberts"), ("Mary","Maryann Roberts")

    DELETE from Junk Where ID>4

    И INSERT, и DELETE работали в этом случае

    Очевидно, вы не можете обновлять какие-либо поля, которые агрегированы или рассчитаны, но любое представление, которое является просто прямым представлением, должно быть обновляемым.

    Если представление содержит более одной таблицы, вы не можете вставлять или удалять, но если представление является подмножеством одной таблицы, то вы обычно можете.

    В дополнение к приведенным выше комментариям я хотел бы добавить несколько замечаний о Views.

    1. Представления могут использоваться для скрытия сложности. Представьте себе сценарий, в котором 5 человек работают над проектом, но только один из них слишком хорош с базой данных, например сложными объединениями. В таком сценарии он может создавать виды, которые могут быть легко запрошены другими членами команды, поскольку они запрашивают какую-либо одну таблицу.
    2. Безопасность может быть легко реализована Views. Предположим, что мы сотрудник таблицы, который содержит чувствительные столбцы, такие как Зарплата , номер SSN . Эти столбцы не должны отображаться для пользователей, которым не разрешено их просматривать. В этом случае мы можем создать представление, которое будет выбирать столбцы в таблице, не требующие авторизации, такие как имя , возраст и т. Д., Не подвергая уязвимые столбцы (например, о зарплате и т. Д., О которых мы упоминали ранее). Теперь мы можем удалить разрешение для прямого запроса к таблице Employee и просто сохранить разрешение на чтение в представлении. Таким образом, мы можем реализовать безопасность с помощью Views.

    В Microsoft SQL Server для реализации и автоматизации своих собственных алгоритмов (расчётов ) можно использовать хранимые процедуры, поэтому сегодня мы с Вами поговорим о том, как они создаются, изменяются и удаляются.

    Но сначала немного теории, чтобы Вы понимали, что такое хранимые процедуры и для чего они нужны в T-SQL.

    Примечание! Начинающим программистам рекомендую следующие полезные материалы на тему T-SQL:

    • Для более подробного изучения языка T-SQL также рекомендую почитать книгу - Путь программиста T-SQL. Самоучитель по языку Transact-SQL .

    Что такое хранимые процедуры в T-SQL?

    Хранимые процедуры – это объекты базы данных, в которых заложен алгоритм в виде набора SQL инструкций. Иными словами, можно сказать, что хранимые процедуры – это программы внутри базы данных. Хранимые процедуры используются для сохранения на сервере повторно используемого кода, например, Вы написали некий алгоритм, последовательный расчет или многошаговую SQL инструкцию, и чтобы каждый раз не выполнять все инструкции, входящие в данный алгоритм, Вы можете оформить его в виде хранимой процедуры. При этом, когда Вы создаете процедуру SQL, сервер компилирует код, а потом, при каждом запуске этой процедуры SQL сервер уже не будет повторно его компилировать.

    Для того чтобы запустить хранимую процедуру в SQL Server, необходимо перед ее названием написать команду EXECUTE, также возможно сокращенное написание данной команды EXEC. Вызвать хранимую процедуру в инструкции SELECT , например, как функцию уже не получится, т.е. процедуры запускаются отдельно.

    В хранимых процедурах, в отличие от функций, уже можно выполнять операции модификации данных такие как: UNSERT, UPDATE, DELETE. Также в процедурах можно использовать SQL инструкции практически любого типа, например, CREATE TABLE для создания таблиц или EXECUTE, т.е. вызов других процедур. Исключение составляет несколько типов инструкций таких как: создание или изменение функций, представлений, триггеров, создание схем и еще несколько других подобных инструкций, например, также нельзя в хранимой процедуре переключать контекст подключения к базе данных (USE).

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

    Хранимые процедуры очень полезны, они помогают нам автоматизировать или упростить многие операции, например, Вам постоянно требуется формировать различные сложные аналитические отчеты с использованием сводных таблиц, т.е. оператора PIVOT. Чтобы упростить формирование запросов с этим оператором (как Вы знаете, у PIVOT синтаксис достаточно сложен ), Вы можете написать процедуру, которая будет Вам динамически формировать сводные отчеты, например, в материале «Динамический PIVOT в T-SQL » представлен пример реализации данной возможности в виде хранимой процедуры.

    Примеры работы с хранимыми процедурами в Microsoft SQL Server

    Исходные данные для примеров

    Все примеры ниже будут выполнены в Microsoft SQL Server 2016 Express . Для того чтобы продемонстрировать, как работают хранимые процедуры с реальными данными, нам нужны эти данные, давайте их создадим. Например, давайте создадим тестовую таблицу и добавим в нее несколько записей, допустим, что это будет таблица, содержащая список товаров с их ценой.

    Инструкция создания таблицы CREATE TABLE TestTable( INT IDENTITY(1,1) NOT NULL, INT NOT NULL, VARCHAR(100) NOT NULL, MONEY NULL) GO -- Инструкция добавления данных INSERT INTO TestTable(CategoryId, ProductName, Price) VALUES (1, "Мышь", 100), (1, "Клавиатура", 200), (2, "Телефон", 400) GO --Запрос на выборку SELECT * FROM TestTable

    Данные есть, теперь давайте переходить к созданию хранимых процедур.

    Создание хранимой процедуры на T-SQL – инструкция CREATE PROCEDURE

    Хранимые процедуры создаются с помощью инструкции CREATE PROCEDURE , после данной инструкции Вы должны написать название Вашей процедуры, затем в случае необходимости в скобочках определить входные и выходные параметры. После этого Вы пишите ключевое слово AS и открываете блок инструкций ключевым словом BEGIN, закрываете данный блок словом END. Внутри данного блока Вы пишите все инструкции, которые реализуют Ваш алгоритм или какой-то последовательный расчет, иными словами, программируете на T-SQL.

    Для примера давайте напишем хранимую процедуру, которая будет добавлять новую запись, т.е. новый товар в нашу тестовую таблицу. Для этого мы определим три входящих параметра: @CategoryId – идентификатор категории товара, @ProductName - наименование товара и @Price – цена товара, данный параметр будет у нас необязательный, т.е. его можно будет не передавать в процедуру (например, мы не знаем еще цену ), для этого в его определении мы зададим значение по умолчанию. Эти параметры в теле процедуры, т.е. в блоке BEGIN…END можно использовать, так же как и обычные переменные (как Вы знаете, переменные обозначаются знаком @ ). В случае если Вам нужно указать выходные параметры, то после названия параметра указывайте ключевое слово OUTPUT (или сокращённо OUT ).

    В блоке BEGIN…END мы напишем инструкцию добавления данных, а также в завершении процедуры инструкцию SELECT, чтобы хранимая процедура вернула нам табличные данные о товарах в указанной категории с учетом нового, только что добавленного товара. Также в этой хранимой процедуре я добавил обработку входящего параметра, а именно удаление лишних пробелов в начале и в конце текстовой строки с целью исключения ситуаций, когда случайно занесли несколько пробелов.

    Вот код данной процедуры (его я также прокомментировал ).

    Создаем процедуру CREATE PROCEDURE TestProcedure (--Входящие параметры @CategoryId INT, @ProductName VARCHAR(100), @Price MONEY = 0) AS BEGIN --Инструкции, реализующие Ваш алгоритм --Обработка входящих параметров --Удаление лишних пробелов в начале и в конце текстовой строки SET @ProductName = LTRIM(RTRIM(@ProductName)); --Добавляем новую запись INSERT INTO TestTable(CategoryId, ProductName, Price) VALUES (@CategoryId, @ProductName, @Price) --Возвращаем данные SELECT * FROM TestTable WHERE CategoryId = @CategoryId END GO

    Запуск хранимой процедуры на T-SQL – команда EXECUTE

    Запустить хранимую процедуру, как я уже отмечал, можно с помощью команды EXECUTE или EXEC. Входящие параметры передаются в процедуры путем простого их перечисления и указания соответствующих значений после названия процедуры (для выходных параметров также нужно указывать команду OUTPUT ). Однако название параметров можно и не указывать, но в этом случае необходимо соблюдать последовательность указания значений, т.е. указывать значения в том порядке, в котором определены входные параметры (это относится и к выходным параметрам ).

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

    Вот несколько разных, но эквивалентных способов запуска хранимых процедур, в частности нашей тестовой процедуры.

    1. Вызываем процедуру без указания цены EXECUTE TestProcedure @CategoryId = 1, @ProductName = "Тестовый товар 1" --2. Вызываем процедуру с указанием цены EXEC TestProcedure @CategoryId = 1, @ProductName = "Тестовый товар 2", @Price = 300 --3. Вызываем процедуру, не указывая название параметров EXEC TestProcedure 1, "Тестовый товар 3", 400

    Изменение хранимой процедуры на T-SQL – инструкция ALTER PROCEDURE

    Внести изменения в алгоритм работы процедуры можно с помощью инструкции ALTER PROCEDURE . Иными словами, для того чтобы изменить уже существующую процедуру, Вам достаточно вместо CREATE PROCEDURE написать ALTER PROCEDURE, а все остальное изменять по необходимости.

    Допустим, нам необходимо внести изменения в нашу тестовую процедуру, скажем, параметр @Price, т.е. цену, мы сделаем обязательным, для этого уберём значение по умолчанию, а также представим, что у нас пропала необходимость в получении результирующего набора данных, для этого мы просто уберем инструкцию SELECT из хранимой процедуры.

    Изменяем процедуру ALTER PROCEDURE TestProcedure (--Входящие параметры @CategoryId INT, @ProductName VARCHAR(100), @Price MONEY) AS BEGIN --Инструкции, реализующие Ваш алгоритм --Обработка входящих параметров --Удаление лишних пробелов в начале и в конце текстовой строки SET @ProductName = LTRIM(RTRIM(@ProductName)); --Добавляем новую запись INSERT INTO TestTable(CategoryId, ProductName, Price) VALUES (@CategoryId, @ProductName, @Price) END GO

    Удаление хранимой процедуры на T-SQL – инструкция DROP PROCEDURE

    В случае необходимости можно удалить хранимую процедуру, это делается с помощью инструкции DROP PROCEDURE .

    Например, давайте удалим созданную нами тестовую процедуру.

    DROP PROCEDURE TestProcedure

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

    У меня все, надеюсь, материал был Вам интересен и полезен, пока!

    Хранимая процедура (англ. stored procedure) – это именованный программный объект БД. В SQL Server есть хранимые процедуры нескольких типов.

    Системные хранимые процедуры (англ. system stored procedure) поставляются разработчиками СУБД и используются для выполнения действий с системным каталогом или получения системной информации. Их названия обычно начинаются с префикса "sp_". Запускаются хранимые процедуры всех типов с помощью команды EXECUTE, которую можно сократить до ЕХЕС. Например, хранимая процедура sp_helplogins, запущенная без параметров, формирует два отчета об именах учетных записей (англ. logins) и соответствующих им в каждой БД пользователях (англ. users).

    EXEC sp_helplogins;

    Чтобы дать представление о действиях, выполняемых с помощью системных хранимых процедур, в табл. 10.6 приведены некоторые примеры. Всего же системных хранимых процедур в SQL Server более тысячи.

    Таблица 10.6

    Примеры системных хранимых процедур SQL Server

    Пользователю доступно создание хранимых процедур в пользовательских БД и в БД для временных объектов. В последнем случае хранимая процедура будет являться временной. Так же как в случае с временными таблицами, название временной хранимой процедуры должно начинаться с префикса "#", если это локальная временная хранимая процедура, или с "##" – если глобальная. Локальная временная процедура может использоваться только в рамках соединения, в котором ее создали, глобальная – и в рамках других соединений.

    Программируемые объекты SQL Server могут создаваться как с использованием средств Transact-SQL, так и с помощью сборок (англ. assembly) в среде CRL (Common Language Runtime) платформы Microsoft.Net Framework . В данном учебнике будет рассматриваться только первый способ.

    Для создания хранимых процедур используется оператор CREATE PROCEDURE (можно сократить до PROC), формат которого приведен ниже:

    CREATE {PROC I PROCEDURE) proc_name [ ; number ]

    [{gparameter data_type }

    [“default] |

    [ WITH [ ,...n ] ]

    [ FOR REPLICATION ]

    AS {[ BEGIN ] sql_statement [;] [ ...n ] [ END ] }

    Если хранимая процедура (или триггер, функция, представление) создается с опцией ENCRYPTION, ее код преобразуется таким образом, что текст становится нечитаемым. В то же время, как отмечается в , используемый алгоритм перенесен из ранних версий SQL Server и не может рассматриваться в качестве надежного алгоритма защиты – существуют утилиты, позволяющие быстро выполнить обратное преобразование.

    Опция RECOMPILE указывает на то, что при каждом вызове процедуры система будет перекомпилировать текст. В обычном случае скомпилированная при первом запуске процедура сохраняется в кэше, что позволяет увеличить быстродействие.

    EXECUTE AS определяет контекст безопасности, в котором должна быть выполнена процедура. Далее указывается одно из значений f CALLER | SELF | OWNER | " user_name"). CALLER является значением по умолчанию и означает, что код будет выполняться в контексте безопасности пользователя, вызывающего этот модуль. Соответственно, пользователь должен иметь разрешения не только на сам программируемый объект, но и на другие затрагиваемые им объекты БД. EXECUTE AS SELF означает использование контекста пользователя, создающего или изменяющего программируемый объект. OWNER указывает, что код будет выполняться в контексте текущего владельца процедуры. Если для нее не определен владелец, то подразумевается владелец схемы, к которой она относится. EXECUTE AS "user_name" позволяет явно указать имя пользователя (в одинарных кавычках).

    Для процедуры могут указываться параметры. Это локальные переменные, используемые для передачи значений в процедуру. Если параметр объявлен с ключевым словом OUTPUT (или сокращенно OUT), он является выходным: заданное ему в процедуре значение после ее окончания может быть использовано вызвавшей процедуру программой. Ключевое слово READONLY означает, что значение параметра не может быть изменено внутри хранимой процедуры.

    Параметрам могут быть назначены значения но умолчанию, которые будут использованы, если при вызове процедуры значение параметра не будет указано в явном виде. Рассмотрим пример:

    CREATE PROC surma (@а int, @b int=0,

    ©result int OUTPUT) AS

    SET @result=0a+0b

    Мы создали процедуру с тремя параметрами, причем у параметра @b значение по умолчанию =0, а параметр @result – выходной: через него возвращается значение в вызвавшую программу. Выполняемые действия достаточно просты – выходной параметр получает значение суммы двух входных.

    При работе в SQL Server Management Studio созданную хранимую процедуру можно найти в разделе программируемых объектов БД (англ. Programmability) в подразделе для хранимых процедур (рис. 10.2).

    При вызове процедуры в качестве входных параметров можно использовать как переменные, так и константы. Рассмотрим два примера. В первом входные параметры процедуры явно заданы константами, для выходного параметра в вызове указано ключевое слово OUTPUT. Во втором варианте в качестве первого входного параметра используется значение переменной, а для второго параметра с помощью ключевого слова DEFAULT указано, что должно быть использовано значение по умолчанию:

    Рис. 10.2.

    DECLARE @с int;

    EXEC summa 10,5,@c OUTPUT;

    PRINT 0c; – будет выведено 15

    DECLARE Gi int = 5;

    – при вызове используем значение по умолчанию

    EXEC summa Gi,DEFAULT , 0с OUTPUT;

    PRINT 0c; – будет выведено 5

    Рассмотрим теперь пример с анализом кода возврата, с которым заканчивается процедура. Пусть надо подсчитать, сколько в таблице Bookl книг, изданных в заданном диапазоне лет. При этом если начальный год оказался больше конечного, процедура возвращает "1" и подсчет не проводит, иначе – считаем количество книг и возвращаем 0:

    CREATE PROC dbo.rownum (0FirsYear int, GLastYear int, 0result int OUTPUT) AS

    IF 0FirsYear>0LastYear RETURN 1

    SET @result= (SELECT COUNT(*) FROM dbo.Bookl

    WHERE BETWEEN 0FirsYear AND 0LastYear) ;

    Рассмотрим вариант вызова данной процедуры, в котором код возврата сохраняется в целочисленной переменной 0ret, после чего анализируется его значение (в данном случае это будет 1). Используемая в операторе PRINT функция CAST служит для преобразования значения целочисленной переменной Gres к строковому типу:

    DECLARE 0ret int, Gres int

    EXEC Gret = rownum 2004, 2002, Gres OUT;

    IF 0ret=l PRINT "Начальный год больше конечного"

    PRINT "Число книг "+ CAST(Gres as varchar(20))

    Хранимые процедуры могут не только считывать данные из таблицы, но и изменять данные и даже создавать таблицы и ряд других объектов БД.

    Однако создавать схемы, функции, триггеры, процедуры и представления из хранимой процедуры нельзя.

    Следующий пример иллюстрирует как эти возможности, так и вопросы, связанные с областью видимости временных объектов. Приведенная ниже хранимая процедура проверяет наличие временной таблицы #ТаЬ2; если этой таблицы нет, то создает ее. После этого в таблицу #ТаЬ2 заносятся значения двух столбцов, и содержимое таблицы выводится оператором SELECT:

    CREATE PROC My_Procl (@id int, @name varchar(30))

    IF OBJECT_ID("tempdb.dbo.#Tab21) IS NULL

    INSERT INTO dbo.#Tab2 (id, name)VALUES (0id,0name)

    SELECT * FROM dbo. #Tab2 –№1

    Перед первым вызовом хранимой процедуры создадим используемую в ней временную таблицу #ТаЬ2. Обратите внимание на оператор ЕХЕС. В предыдущих примерах параметры передавались в процедуру "по позиции", а в данном случае используется другой формат передачи параметров – "по имени", явно указывается имя параметра и его значение:

    CREATE TABLE dbo.#Tab2 (id int, name varchar(30));

    EXEC My_Procl 0name="lvan", 0id=2;

    SELECT * FROM dbo.#Tab2; –№2

    В приведенном примере оператор SELECT отработает дважды: первый раз – внутри процедуры, второй раз – из вызывающего фрагмента кода (отмечен комментарием "№ 2").

    Перед вторым вызовом процедуры удалим временную таблицу #ТаЬ2. Тогда одноименная временная таблица будет создана из хранимой процедуры:

    DROP TABLE dbo.#Tab2;

    EXEC My_Procl 0name="Ivan", 0id=2;

    SELECT * FROM dbo.#Tab2; –№2

    В этом случае данные выведет только оператор SELECT, находящийся внутри процедуры (с комментарием "Ха 1"). Выполнение SELECT "№ 2" приведет к ошибке, так как созданная в хранимой процедуре временная таблица на момент возврата из процедуры будет уже удалена из базы tempdb.

    Удалить хранимую процедуру можно с помощью оператора DROP PROCEDURE. Его формат представлен ниже. Одним оператором можно удалить несколько хранимых процедур, перечислив их через запятую:

    DROP (PROC I PROCEDURE) { procedure } [

    Например, удалим ранее созданную процедуру summa:

    DROP PROC summa;

    Внести изменения в существующую процедуру (а фактически – переопределить ее) можно с помощью оператора ALTER PROCEDURE (допу

    стимо сокращение PROC). За исключением ключевого слова ALTER, формат оператора практически совпадает с форматом CREATE PROCEDURE. Например, изменим процедуру dbo. rownum, установив ей опцию выполнения в контексте безопасности владельца:

    ALTER PROC dbo.rownum (SFirsYear int,

    SLastYear int, Sresult int OUTPUT)

    WITH EXECUTE AS Owner – устанавливаемая опция

    IF 0FirsYear>0LastYear RETURN 1 ELSE BEGIN

    SET 0result= (SELECT COUNT(*) FROM dbo.Bookl

    WHERE BETWEEN SFirsYear AND SLastYear);

    В некоторых случаях может возникнуть необходимость в динамическом формировании команды и выполнении ее на сервере БД. Эта задача также может решаться с помощью оператора ЕХЕС. В приведенном ниже примере выполняется выборка записей из таблицы Bookl по условию равенства атрибута Year значению, задаваемому с помощью переменной:

    DECLARE 0у int = 2000;

    EXEC ("SELECT * FROM dbo.Bookl WHERE = "+@y) ;

    Выполнение динамически сформированных инструкций создает предпосылки для реализации компьютерных атак типа "SQL-инъекция" (англ. SQL injection). Суть атаки заключается в том, что нарушитель внедряет в динамически формируемый запрос собственный код на SQL. Обычно это происходит, когда подставляемые параметры берут из результатов ввода данных пользователем.

    Несколько изменим предыдущий пример:

    DECLARE 0у varchar(100);

    SET 0у="2ООО"; – это мы получили от пользователя

    Если предположить, что присваиваемое в операторе SET строковое значение мы получили от пользователя (неважно каким образом, например, через веб-приложение), то пример иллюстрирует "штатное" поведение нашего кода.

    DECLARE 0у varchar(100);

    SET 0у="2000; DELETE FROM dbo.Book2"; – инъекция

    EXEC ("SELECT * FROM dbo.Book2 WHERE ="+0y);

    В рекомендуется по возможности использовать в подобных случаях системную хранимую процедуру sp_executcsql, которая позволяет контролировать тип параметров, что является одним из барьеров на пути SQL- инъекций. Не рассматривая в подробностях ее формат, разберем пример, аналогичный представленному ранее:

    EXECUTE sp_executesql

    N"SELECT * FROM dbo.Bookl WHERE =0y",

    Здесь явно указывается тип используемого в запросе параметра, и SQL Server при выполнении будет его контролировать. Буква "N" перед кавычками указывает, что это литерная константа в формате Unicode, как того требует процедура. Параметру можно присвоить не только постоянное значение, но и значение другой переменной.