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

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

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

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

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

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

Погуглил этот отличный пост.

ORM и LINQ to SQL кажутся текущими тенденциями замены StoredProcs.

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

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

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

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

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

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

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

Например, если это просто

select a from b where x = y

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

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

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

Просто кидаю сюда свой маленький совет. До SQL 2005 (может быть, даже дальше) SP были быстрее. Однако SQL Server 2005 и более поздние версии действительно оптимизированы и кэшируют ваши запросы по мере их использования. Фактически, мы перенесли веб-приложение на новый SQL-сервер. Приложение запускалось медленным для всех. Все запускалось «3/4 секунды» или 1 секунду. Затем SQL начал компилировать наиболее часто используемый запрос, и все пошло от медленного до очень быстрого.

Конечно, мы поменяли местами сервер, когда на нем работало много людей (что может объяснить, почему сначала он был медленным). Но поверьте мне. СП еще не закончились. У них просто есть другое применение, кроме привязки к приложению.

Этот вопрос также перетекает в один опубликован ранее сегодня.

Когда вы объединяете SP с логикой с самой базой данных, вы эффективно конвертируете БД во что-то вроде сервера приложений.

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

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

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

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

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

ЭТО ДЛЯ ЧЕГО ПРЕДНАЗНАЧЕН СЛОЙ СЛУЖБЫ!

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

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

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

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

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

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

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

Хорошая система должна сочетать и то и другое. Вероятно, следуя принципу 80-20, 20 - ИП.

Может быть, хранимые процедуры Джеффа Этвуда знает будут существовать вечно и просто пытаются стимулировать размышления и дискуссии? Мне нравится думать, что он действительно хотел бы написать убедительное эссе под названием «Хранимые процедуры считаются вредными» :)

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

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

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

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

Могу добавить, что некоторую работу лучше выполнять на уровне БД. например Результаты кросс-таблицы в SQL 2005, Рекурсивные запросы.

Я согласен с тем, что некоторые простые вещи, такие как SELECT, INSERT, UPDATE, DELETE, могут быть выполнены с помощью ORM, Linq.

Итак, глупо говорить, что дни хранимых процедур прошли. Сколько людей действительно должны беспокоиться об изменении платформы БД (SQL на Mysql, Oracle)?

Частично это обусловлено доступностью нереляционных хранилищ данных. SP обычно подразумевают реляционную базу данных; ORM и Linq предлагают возможность создавать уровни абстракции, которые богаче, чем предлагает SQL, и иногда лучше соответствуют абстракциям, которые мы используем в других частях проекта (проблема «несоответствия импеданса»).

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

Они не так удобны, если ваше хранилище данных - xml или аналитическая база данных.

Ба!

ORM, SP, View, Magic Wands или что-то еще.

У каждого «инструмента» есть свое место в вашем поясе, используйте инструменты с умом.

Единственное, что «изменилось» (действительно улучшилось), это то, что некоторые ORM имеют уже встроенные хорошие инструменты кэширования, а MySql и Sql 2005+ могут обрабатывать динамическое или специальное кэширование планов запросов / выполнения.

Потенциальная потеря производительности из-за бросания всех видов динамического sql на ваш сервер db была несколько смягчена. Теперь просто обойтись без хранимых процедур. Сохраненные процессы никуда не денутся.

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

Приложение №1 - вам необходимо добавить новую связь / поле или изменить значение столбца, допускающего значение NULL, на значение, отличное от NULL.

Приложение № 2-10 - Может использовать или не использовать этот объект базы данных

Первое, что я хочу сделать, это проверить зависимости объекта базы данных, чтобы определить, как он используется и сломаю ли я что-нибудь. Угадайте, что, если у вас есть куча внешних запросов VIA ORM / SQL, вы бы не имели представления о зависимостях.

Это единственный недостаток, который я обнаружил, имея прямой доступ к таблицам.

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

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