Хранимые процедуры - конец дня

Question

Я слушаю подкаст Hanselminutes; «StackOverflow использует ASP.NET MVC - Джефф Этвуд и его техническая команда». В ходе подкаста они говорят о SQL-сервере и говорят что-то вроде «Дни хранимой процедуры прошли».

Теперь я не администратор, но это застало меня врасплох. Я всегда предполагал, что SP были способом достижения скорости (как они соблюдаются) и безопасности, не говоря уже о масштабируемости и ремонтопригодности. Если это не так, и ИП на последних ногах, что их заменит или что нам делать в будущем?

Answer 1

Может быть, я слишком старая школа, или слишком ленив, или оба, но я должен не согласиться. Снова и снова хранимые процедуры «спасли день», потому что когда появляется незначительное внутреннее изменение или ошибка , нам нужно только исправить хранимую процедуру вместо обновления настольного приложения на нескольких десятках рабочих столов плюс веб-сервер , Кроме того, пользователи не прерываются. Это экономит много усилий и хлопот пользователя.

Кроме того, некоторые операции с БД на сервере будут более эффективными, а не переходят туда-сюда по сети, особенно. когда одна хранимая процедура вызывает другую, которая вызывает другую и т. д. (с курсорами или без них)

РЕДАКТИРОВАТЬ: в архитектуре SOA проблема с обновлением клиентских приложений смягчена (спасибо maud-dib), но хранимые процедуры, вызывающие друг друга, все еще более эффективны, чем многочисленные обходы сети на уровне SOA. И обновление уровня SOA тоже не всегда тривиально.

Answer 2

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

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

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

Answer 3

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

Погуглил этот великий пост.

Answer 4

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

ЭТО ТО, ЧТО СЛУЖЕБНЫЙ СЛОЙ!

Бизнес-логика идет в сервисном слое, логика приложения - в приложении / веб-сайте.

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

Answer 5

SP - это, пожалуй, тот путь, если вас беспокоит ТОЛЬКО скорость. Но если вы заботитесь о масштабируемости или ремонтопригодности, SP могут быть не лучшими. Наша архитектура построена на SP, и после 10 лет написания кода ее очень сложно поддерживать и она очень глючная. Хороший картограф ORM может быть лучшим выбором.

Answer 6

Maintenability Возможно, ИП лучше. Если сложно поддерживать сотни SP, поддерживать их в компонентах бизнес-уровня еще сложнее.

Performance Кэширование запросов может привести к производительности, близкой к SP. Но они не могут сравниться с производительностью SP разных типов баз данных в разных платформах. Задержка сети является еще одной проблемой, хотя в настоящее время этот разрыв сокращается.

Debug Вероятно, это довольно просто с SP, чем отладка бизнес-уровня + уровня БД вместе взятых.

Может быть еще больше + ve очков, используя SP.

Но если взглянуть на современную тенденцию программирования, то достаточно «разумно» использовать архитектуру «N» по многим причинам бизнеса, чем придерживаться «старого» подхода на основе SP.

Хорошая система должна иметь смесь обоих. Вероятно, следуя принципу 80-20, из которых 20 - СП.

Answer 7

Хранимые процедуры полезны для вещей, которые не CRUD - таких как специализированная кросс-таблица логики, которая лучше всего выполняется в БД. Операции CRUD не должны использовать SP, если они не являются автоматически сгенерированным выходом инструмента ORM, такого как TableAdapters.

Answer 8

ORM и LINQ to SQL, похоже, являются современными тенденциями для замены StoredProcs.

Лично я использовал ORM, и мне гораздо проще поддерживать и поддерживать.

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

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

Answer 9

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

Если вы думаете об инкапсуляции, вы можете рассматривать БД как объект, а SP как методы и свойства, которые открывают функциональность объектов для внешнего мира.

В некоторых более крупных средах разработки разработчики пользовательского интерфейса и бизнес-уровня не допускаются рядом с БД. Они определяют свои требования, а отдельная команда предоставляет и взаимодействует через SP.

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

Answer 10

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

Я ни в коем случае не убежден, что используемая в LINQ 2 SQL ORM на один бит быстрее, чем sproc.