Почему мне нужны Хранимые процедуры, когда у меня есть LINQ к SQL

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

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

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

Простой пример:

select * from Products where GetCategoryType(CategoryName)=1

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

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

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

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

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

Sprocs имеют свое использование, точно так же, как использование LINQ делает. IMO, если операция выполняется многократно в нескольких местах затем, это - хороший кандидат на "рефакторинг" в Сохраненный Proc, в противоположность оператору LINQ, который повторяется в различных местах.

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

Лично, я не забочусь о LINQ. Мне нравится разделение материала манипулирования данными и материала кода. Кроме того, анонимные типы, которые сгенерированы от оператора LINQ, не могут быть переданы - прочь другим слоям n-tier приложения, таким образом, или тип должен быть конкретно определен, или вызов LINQ должен быть выполнен в UI. Gack!

Кроме того, существуют проблемы безопасности (безотносительно пользователя, которого код LINQ звонит в SQL Server MS под потребностями иметь беспрепятственный доступ к данным, поэтому если то имя пользователя/пароль поставлено под угрозу, так данные).

И наконец, LINQ к SQL только работает на SQL Server MS (как это прибывает из MS).

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

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

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

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

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

Существуют значительные связанные повышения производительности на стороне SQL Server вещей при использовании хранимых процедур при соответствующих обстоятельствах.

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

• При работе с большими таблицами, может быть трудно генерировать эффективный запрос с помощью LINQ для SQL.
• DBA А может проанализировать и troubleshout хранимые процедуры. Но думайте о том, что происходит, когда два усложнил операции LINQ от различного столкновения фронтендов.
• Хранимые процедуры могут осуществить целостность данных. Отклоните доступ для записи на таблицах и позвольте изменения только через хранимую процедуру.
• хранимые процедуры Обновления так же легко как выполняющий ALTER PROCEDURE на сервере. Если развертывание займет месяцы и сценарий минуты, Вы будете более гибкими с хранимыми процедурами.

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

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

1. это делает конфигурацию безопасности легче (как упомянуто другими плакатами).
2. Это обеспечивает ясно определенный интерфейс для доступа DB (хотя ответственность за это могла быть переложена в другие области, такие как DAL, записанный в C#
3. , я нахожу, что Оптимизатор запросов, в Oracle, по крайней мере, может принять более интеллектуальные решения больше информации, которую Вы даете ему. Это действительно требует тестирования с обоими методами хотя для Ваших определенных сценариев все же.
4. В зависимости от доступных разработчиков, у Вас могут быть некоторые очень хорошие кодеры SQL, которые будут лучше в создании эффективных запросов, если они будут использовать sprocs.

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

1. Stored Procedures и Linq к Sql решают различные проблемы.

2. Linq к Sql конкретен к Microsoft SQL Server.

А-ч, предмет многих дебатов.

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

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

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

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

Безопасность.

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

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

если это - все, что Вы когда-либо делали в sql, Вам не был нужен sprocs прежде!

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

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

Скажем, что время от времени вам нужно архивировать элементы из одной таблицы в другую или делать аналогичные вещи. С LINQ это означало бы получить, скажем, один миллион строк из таблицы A в клиенте СУБД, а затем вставить их в таблицу B.

С хранимой процедурой все работает нормально, в наборах.