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

Ответ 1

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

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

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

Ответ 2

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

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

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

Ответ 3

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

Пошел в эту замечательную статью.

Ответ 4

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

Ответ 5

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

ЭТО ТАКОЕ СЛУЖЕБНЫЙ СЛОЙ!

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

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

Ответ 6

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

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

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

В SP могут быть еще больше + ve точек.

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

Хорошая система должна иметь сочетание обоих. Вероятно, следующий принцип 80-20, 20 - SP.

Ответ 7

ORM и LINQ to SQL, по-видимому, являются текущими тенденциями замены StoredProcs.

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

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

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

Ответ 8

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

Ответ 9

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

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

Ответ 10

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

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

Ответ 11

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

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

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

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

Ответ 12

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

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

select a from b where x = y

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

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

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

Ответ 13

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

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

Ответ 14

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

Ответ 15

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

Ответ 16

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

Ответ 17

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

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

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

Ответ 18

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

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

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

Ответ 19

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

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

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

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

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

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

Ответ 20

Ба!

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

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

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

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