Лучше всего использовать хранимую процедуру для каждого SQL-вызова в .NET-приложениях?SQL хранимая процедура для каждого отдельного оператора SQL в .NET?
Поддерживается ли это по соображениям производительности и уменьшению площади поверхности для атак SQL-инъекций (в веб-приложениях)?
Хранимые процедуры имеют несколько преимуществ по сравнению с параметризованных запросов:
При использовании исключительно, вы можете отключить CREATE, INSERT, SELECT, UPDATE, ALTER, DROP, DELETE, и т.д. доступ для приложения учетные записи, и таким образом добавьте небольшую сумму безопасности.
Они обеспечивают согласованный, управляемый интерфейс, когда у вас есть несколько приложений, использующих одну и ту же базу данных.
Использование процедур позволяет администратору баз данных управлять и настраивать запросы даже после развертывания приложения.
Развертывание небольших изменений и исправлений ошибок намного проще.
Они также имеют несколько недостатков:
Количество процедур может быстро вырасти до точки, где их содержание трудно, и в настоящее время инструменты не обеспечивают простой способ для адекватной документации ,
Параметрированные запросы помещают код базы данных рядом с местом, где он используется. Хранимые процедуры очень далеки друг от друга, что затрудняет поиск сложного кода.
Сохраненные процедуры сложнее.
Вам нужно будет взвесить эти расходы/выгоды для вашей системы.
No.
Если вы посылаете запросы к SQL Server в качестве параметризованных запросов, SQL Server будет кэшировать план выполнения и будет дезинфицировать свои входные параметры, чтобы не допустить атаки SQL-инъекции.
Это всего лишь один способ сделать что-то. Upsides включают в себя сохранение всего вашего кода SQL в одном месте, проверка procs для синтаксиса во время создания и возможность установки разрешений на procs, которые обычно представляют собой своего рода «действие» и хорошо подходят для концептуальной модели безопасности.
Недостатки включают массовое количество проков для любого среднего или большего применения и все домашнее хозяйство, которое поставляется с этим.
Продукт моего работодателя использует прозы для всего, и я должен сказать, что при правильной практике это вполне сносно.
Я предпочитаю хранить procs по встроенному SQL, так как SQL является одним консолидированным местом; однако я предпочитаю использовать такой инструмент, как nHibernate, который будет автоматически генерировать SQL для меня, тогда у вас нет SQL, о котором нужно беспокоиться!
Есть еще одно преимущество - когда речь заходит о настройке, особенно для клиента, ее можно легко сделать с помощью SP (добавив подсказки или даже переписав код). Со встроенным SQL это практически невозможно.
Это «избегать» или уменьшить риск внедрения sql? Я думал, что для исключения потребуется сильная проверка ввода, Нет? – Shaw 2008-12-04 13:36:07
Пока вы всегда используете параметры, а не используете конкатенацию, SQL-инъекция невозможна. Причина в том, что параметры отделяют синтаксис от значений - все, что содержится в параметрах, не может повлиять на то, как SQL анализируется, потому что это уже сделано. – 2008-12-04 13:42:22
Параметрированные запросы не защищены от SQL-инъекции AFAIK, если код не вызывает sp_executesql или что-то в этом роде. – 2008-12-04 13:43:06