Хранимые процедуры требуются для больших наборов данных?

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

В этом случае Ваши непосредственные выигрыши в производительности:

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

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

1. Структуры данных могут быть абстрагированы далеко от логики программы, позволив структурам базы данных измениться, не требуя изменений в программах, получающих доступ к данным. Любой, кто провел часы grep'ing корпоративная кодовая база для SQL, использующего [mytable] прежде, чем внести простое изменение базы данных, будет ценить это.
2. SPS может обеспечить уровень безопасности, хотя это можно злоупотребить и сверхполагаться.

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

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

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

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

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

Я предполагаю, что Ваша база данных отчетов является хранилищем данных и что данные являются ETL'ed и сохраненный в в формате в целях сообщить. Где я в настоящее время работаю, это - обычная практика.

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

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

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

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

При обработке больших количеств строк, где индексы доступны и SQL относительно настраивается, механизм базы данных, выполняющий основанные на наборе операции непосредственно на данных - через SQL, скажите - будет почти всегда превосходить обработку строки строкой по характеристикам (даже на том же сервере) в клиентском инструменте. Данные не пересекают физического или логического boudaries, чтобы оставить процессы сервера базы данных или оставить сервер базы данных и выйти по сети. Даже выполнение RBAR (строка мучительной строкой) на сервере будет быстрее, чем выполнение его в клиентском инструменте, если только ограниченный объем данных действительно должен когда-либо оставлять сервер, потому что...

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

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

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

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

И да, в зависимости от сложности отчета запрос как это может занять полчаса или дольше...

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

Когда движущиеся данные между таблицами/базами данных, это может быть намного более быстро для использования сохраненного procs, поскольку данные не должны перемещаться между базой данных и приложением. Однако в большинстве случаев я не использовал бы сохраненный proc, поскольку они делают разработку более сложной, я нахожусь в лагере ORM сам. Можно иногда получать большие ускорения путем загрузки партий в RAM и обработки ее там, однако который является полностью другим способом кодировать и не позволит повторное использование логики, которая уже находится в сохраненном procs. Извините я думаю, что Вы - стек с сохраненным proc в то время как в том задании.

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

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

Я мог, возможно, придумать больше, но несколько точек.

1. Принимая современный DB, хранимые процедуры, вероятно, на самом деле не будут заметно быстрее, чем нормальные процедуры из-за кэширования и т.п..
2. Преимущества безопасности Хранимых процедур несколько переоценены.
3. Изменение является злым. Непротиворечивость является королем.

Я сказал бы, что № 3 превосходит все другие проблемы, если хранимые процедуры не вызывают законную проблему.

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

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

Если бы Вы перемещаете большие объемы данных к другим серверам, хотя, я рассмотрел бы использование DTS (при использовании SQL Server 2000) или SSIS. Это может ускорить Ваши процессы еще далее, но это будет зависеть значительно от того, что Вы делаете и как.

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

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

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

Более быстрый путь к созданию отчетов состоит в том, чтобы просто считать все данные в память (требуемая ОС на 64 бита) и просто обойти объекты. Это, конечно, ограничено для трамбовки размера (доступные 32 ГБ) и отчеты, где Вы поражаете значительную часть дб. Никакая потребность приложить усилие для маленьких отчетов.

В былые времена я мог выполнить отчет, запросив более чем 8 миллионов объектов через 1,5 секунды. Это было приблизительно в гигабайте поршня на pentium 4 на 3 ГГц. 64 бита должны быть приблизительно вдвое более медленными, но это компенсируется быстрыми процессорами.