Лучше использовать хранимые процедуры или SQL в моем коде для работы с данными?

Question

Когда речь идет об операциях CRUD и вашей базе данных (SQL Server '08), лучше ли записывать операторы SQL в ваш код или использовать хранимые процедуры? Почему?

Как указано ниже, я опустил LINQ в качестве третьего варианта. Это было сделано, потому что я не знаком с LINQ. , , еще. Если LINQ - лучший вариант, пожалуйста, дайте мне знать, что мне не хватает.

Answer 1

Я предпочитаю хранимые процедуры встраиванию SQL в приложение.

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

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

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

Answer 2

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

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

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

Answer 3

Из этих двух, хранимых процедур, если только по какой-либо другой причине проще изменить хранимую процедуру в производственном процессе, чем развернуть новый код. И, как указывает Кристиан, он менее восприимчив к атакам с использованием инъекций (непараметрический SQL действительно плох в этом).

Есть преимущества в производительности, но они весьма значительны.

Джефф (основатель StackOverflow) любит LINQ to SQL, который отличается от использования хранимых процедур, но в целом безопаснее, чем встроенный код.

Answer 4

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

И вот почему:

1. Заявления, расположенные в вашем коде уязвимы для внедрения кода или любые виды уязвимостей безопасности, которые могут повлиять ваш код, вместо этого хранимые процедуры - лучший способ избежать проблемы с параметрами санации.
2. Хранимые процедуры могут управлять другим независимым уровнем разрешений и безопасность вашего приложения, используя логины SQL и добавление политик каждому пользователю вашей процедуры Магазина.
3. Если вам нужно поделиться некоторыми Прикладная логика к другим вы всегда можете управлять сохраненным процедуры как черные ящики для третьих лиц, защищающие вашу базу данных.

Это лишь некоторые из функций безопасности и лучших практик SQL SP

Answer 5

Зависит от ваших предпочтений.

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

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

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

И я не единственный, кто (в зависимости от ситуации) чувствует это , и я не могу повторить все удивительные замечания, сделанные в сообщении Джеффа в блоге:

Код ужаса: кому нужны хранимые процедуры?

Answer 6

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

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

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

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

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

Я бы всегда располагал своего рода прикладным уровнем поверх базы данных, работающей где-то как служба (веб-служба, служба windows, веб-приложение и т. Д.), И эта служба будет обеспечивать безопасность. Ни один пользователь не может получить прямой доступ к базе данных.

Answer 7

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

Хранимые процедуры плохие, хорошо? (Франс Бума)

Специально для CRUD довольно сложно обосновать, что хранимые процедуры лучше. Хотя у динамического SQL есть свои недостатки, хороший ORM и / или Linq избавляет от большинства из них. Если вы пробовали оба способа в приличных проектах, во что бы то ни стало идите в ногу со своими личными предпочтениями, если у вас есть такая возможность.

Answer 8

Хранимые процедуры и CRUD никогда не имели для меня особого смысла, особенно в случае с R (Read)

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

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

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

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

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

Answer 9

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

С SQL в вашем коде это выглядит грязно, и вы действительно открыты для атак SQL инъекций.

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