Хранимые процедуры против параметризованных запросов

Ответ 1

Из тега .NET(и только из тега) я буду рассматривать SQL Server здесь. Параметризированные запросы отлично подходят для проектов с одним приложением и скромными требованиями безопасности. Требуется меньше усилий для настройки, и многие системы ORM будут использовать их, если вам это нравится или нет.

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

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

Ответ 2

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

Если мне нужно внести существенные изменения в структуру базы данных, которую я бы переписал?

и

Когда я отлаживаю проблему, которая облегчит мне жизнь?

Ответ 3

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

Значительное преимущество хранимых процедур в производительности - хранить данные на сервере sql и не передавать их клиенту для его обработки. Вся идея пакетной обработки данных и минимизация использования курсора.

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

Ответ 4

Богдан уже это сказал. Подумайте об этом именно так: хотите ли вы написать четкое разделение кода приложения и уровня доступа к данным или хотите быть похожими на тех, кто попустил PHP-программистов, которые вставляют HTML в свои скрипты?

Размещение SQL внутри приложения и вызов БД просты - с точки зрения разработчика приложений, но SP - лучший подход во всех отношениях. После их создания их легко отлаживать (особенно с помощью инструментов, поставляемых с SQL Server).

Конечным подходом является разработка вашего приложения, а затем предоставление требуемым компонентам доступа к данным для DBA для кода для вас - он дает вам API для вызова, а внутренние тонкости при определении того, как вернуть запрошенные данные, вплоть до него, который, как мы надеемся, гораздо больше знает, как сделать отношения данных более эффективными, чем вы могли бы сделать.

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

Ответ 5

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

С точки зрения ремонтопригодности:

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

С точки зрения скорости:

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

В терминах подключения:

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

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

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