Хранимые процедуры - Конец света

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

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

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

Вот еще!

ORM, SPS, Представление, Волшебные палочки, или что бы то ни было.

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

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

потенциальная потеря производительности от броска всех видов динамического sql в Вашем сервере дб была несколько смягчена. Его просто легче обойтись без помощи хранимых процедур теперь. Сохраненные Procs не идут никуда.

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

App#1 - необходимо добавить новые отношения/поле или изменить nullable столбец на не пустой.

App#2-10 - May или не может использовать этот объект базы данных

первая вещь, которую я хочу сделать, проверить мои зависимости от объекта базы данных, чтобы определить, как его используемый и если я буду повреждать что-нибудь. Ну, угадайте то, что, если бы у Вас есть набор внешних запросов ЧЕРЕЗ ORM / SQL, Вы понятия не имели бы о зависимостях.

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

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

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

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

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

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

я соглашаюсь, что часть простого материала, такого как ВЫБОР, ВСТАВЬТЕ, ОБНОВИТЕ, УДАЛИТЕ, может заботиться о ORM, Linq.

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

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

Могло скорее случиться так, что Jeff Atwood знает , хранимые процедуры будут вокруг навсегда и просто пытались стимулировать мысль и дебаты? Мне нравится думать, что то, что он действительно хотел бы сделать, должно записать убедительное эссе, наделенное правом "Хранимые процедуры, Продуманные Вредный" :)

Этот вопрос также выходит за край в один, отправил ранее сегодня .

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

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

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

при размышлении об Инкапсуляции можно рассматривать DB как объект и SPS как методы и свойства, которые выставляют функциональность объектов внешнему миру.

В некоторых больших средах разработки, разработчикам уровня UI и Business не разрешают около DB. Они указывают свои требования, и отдельная команда обеспечивает и интерфейс через SPS

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

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

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

select a from b where x = y

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

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

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

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

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

При объединении SPS с логикой с самой базой данных Вы эффективно преобразовываете DB в во что-то сродни Серверу приложений.

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

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

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

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

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

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

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

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

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

Отладка , вероятно, довольно легка с SPS, чем отладка бизнес-уровня + соединенный уровень дб.

может быть еще больше точек +ve с помощью SPS

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

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

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

ЭТО - то, ДЛЯ ЧЕГО УРОВЕНЬ СЛУЖБ!

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

намного более трудно отладить и поддержать сотни SPS (особенно, если там генерировал), чем это должно поддержать правильно написанный код, который говорит с DB через инструмент ORM.

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

Погугленный это большое сообщение.

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

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

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