Есть ли такая вещь, как слишком много хранимых процедур?У вас слишком много хранимых процедур?
Я знаю, что у вас нет предела количеству, которое вы можете иметь, но это ли какая-либо производительность или архитектурная причина не создавать сотни, тысячи?
Для меня самым большим ограничением для этой сотни или тысячи процедур хранения является ремонтопригодность. Несмотря на то, что это не прямой удар по производительности, он должен быть рассмотрен. Это архитектурная точка зрения, вы должны планировать не только первоначальную разработку приложения, но и будущие изменения и техническое обслуживание.
Это означает, что вы должны проектировать/создавать столько, сколько требуется вашему приложению. Хотя с Hibernate, NHibernate, .NET LINQ я бы постарался сохранить столько логики процедур хранения в коде и только поместить его в базу данных, когда скорость является фактором.
я думаю, что до тех пор, как вы называете их uspXXX и не spXXX на поиск по имени не будет прямой, так что не недостаток - хотя вы могли бы задаться вопросом о том, обобщающие проки, если у вас есть тысячи ...
ли вы имеете в виду кроме того, что вы должны поддерживать их все при внесении изменений в базу данных? Это большая причина для меня. Лучше иметь меньше, которые могут обрабатывать многие сценарии, чем сотни, которые могут обрабатывать только один.
Я бы сказал, что при всех таких вещах обслуживание становится проблемой. Кто знает, каковы все они и какую цель они служат? Что происходит годами, когда они являются просто артефактами унаследованной системы, о которых никто не может вспомнить, для чего они нужны, но напуганы?
Я думаю, что главное - это вопрос не того, возможно ли это, но это должно быть сделано. Все равно одна мысль.
Как говорили другие, это действительно сводится к аспекту управления. Через некоторое время он превращается в поиск пословичной иглы в стоге сена. Тем более, когда существуют плохие стандарты именования ...
Вопрос: почему вы не используете какую-то промежуточную платформу, если вы говорите о сотнях или тысячах хранимых процедур?
Назовите меня старомодным, но я думал, что база данных должна просто хранить данные, и программа (ы) должна быть той, которая принимает решения бизнес-логики.
Нет, не то, что я знаю. Однако у вас должно быть хорошее соглашение об именах для них. Например, запуск их с помощью usp_ - это то, что нравится много poeple (быстрее, чем начиная с sp_).
Возможно, ваши сообщения sprocs должны быть usp_reporting_, а ваши бизнес-объекты должны быть usp_bussiness_ и т. Д. Как долго вы можете управлять ими, не должно быть проблем с их большим количеством.
Если они становятся слишком большими, вы можете разбить базу данных на несколько баз данных. Это может иметь более логичный смысл и может помочь с размером базы данных и т. Д.
Если у вас много хранимых процедур, вы обнаружите, что привязываете себя к одной базе данных - некоторые из них могут быть легко перенесены.
Привязка к одной базе данных не является хорошим дизайном.
Кроме того, если у вас есть бизнес-логика в базе данных и в бизнес-слое, то обслуживание становится проблемой.
В базе данных Oracle вы можете использовать пакеты для группировки связанных процедур вместе.
несколько из тех, и ваше пространство пространства высвободилось.
Ада, у вас может быть слишком много. Я пару лет назад работал над системой, у которой было что-то вроде 10 000 проков. Это было безумие. Люди, которые написали систему, действительно не знали, как программировать, но они знали, как правильно плохо структурировать процессы, поэтому они вносят почти всю логику приложения в proc. Некоторые из procs бежали за тысячами линий. Управление беспорядком было кошмаром.
Слишком много (и я не могу нарисовать вам определенную линию на песке), вероятно, является индикатором плохого дизайна. Кроме того, как указывали другие, есть более эффективные способы достижения гранулярного интерфейса базы данных, не прибегая к массовому количеству процессов.
У меня чуть меньше 200 в коммерческом продукте SQL Server 2005, который, вероятно, увеличится примерно на 10-20 в течение нескольких следующих дней для некоторых новых отчетов.
По возможности я пишу «подпрограммы», так что в любое время, когда я нахожу, что я помещаю 3 или 4 идентичных утверждения вместе более чем в пару sprocs, пришло время превратить эти несколько операторов в подпрограмму, если вы увидите, что я имею в виду.
Я не склонен использовать sprocs для выполнения всей бизнес-логики как таковой, я просто предпочитаю, чтобы sprocs делали что-либо, что можно было бы рассматривать как «транзакционное», поэтому где, как мой код клиента (в Delphi, но что угодно) может сделать нечетную вставку или само обновление, как только что-то требует, чтобы несколько вещей были обновлены или вставлены «сразу», пришло время для sproc.
У меня есть простое, грубое соглашение об именовании для оказания помощи в читаемости (и в обслуживании!)
кодового названия для данного изделия «Рейчли», поэтому у нас есть
RP_whatever - these are general sprocs that update/insert data,
- or return small result sets
RXP_whatever - these are subroutine sprocs that server as 'functions'
- or workers to the RP_ type procs
REP_whatever - these are sprocs that simply act as glorified views almost
- they don't alter data, they return potentially complex result sets
- for reporting purposes, etc
XX_whatever - these are internal test/development/maintenance sprocs
- that the client application (or the local dba) would not normally use
называние произвольно , это просто поможет отличить от префикса sp_, который использует SQL Server.
Я думаю, если бы у меня было 400-500 sprocs в базе данных, я мог бы заинтересоваться, но несколько сотен - это не проблема вообще, если у вас есть система для определения того, какой вид деятельности каждый sproc ответственный за. Я бы предпочел превзойти изменения схемы в нескольких сотнях sprocs (где инструменты SQL Server могут помочь вам найти зависимости и т. Д.), Чем пытаться превзойти изменения схемы на моем языке программирования на высоком уровне.
Да, вы можете.
Слишком много какой-либо конкретной вещи, вероятно, означает, что вы делаете это неправильно. Слишком много файлов конфигурации, слишком много кнопок на экране ...
Невозможно говорить для других СУБД, но приложение Oracle, использующее PL/SQL, должно логически связывать процедуры и функции с пакетами, чтобы предотвратить каскадные недействительности и управлять кодом лучше.
Да, у вас может быть много хранимых процедур.
Соглашения об именах могут действительно помочь в этом.Например, если у вас есть соглашение об именах, в котором всегда есть имя таблицы и InsUpd или Get, довольно легко найти хранимую процедуру , когда вам это нужно. Если у вас нет какого-либо стандартного соглашения об именах, было бы очень легко придумать две (или более) процедуры, которые делают почти то же самое.
Было бы легко найти пару из следующих без стандартизированного именования ... usp_GetCustomersOrder, CustomerOrderGet_sp, GetOrdersByCustomer_sp, spOrderDetailFetch, GetCustOrderInfo и т.д.
Другого дела, что начинает происходить, когда у вас есть много хранимых процедур заключается в том, что у вас будут хранимые процедуры, которые никогда не используются, а некоторые из них редко используются ... Если у вас нет способа отслеживания использования хранимых процедур, вы либо закончите с большим количеством неиспользованных процедуры ... или, что еще хуже, избавление от того, которое, по вашему мнению, никогда не используется и впоследствии выясняется, что оно используется только один раз в год или один раз в квартал. :(
Jeff
Вы должны поместить весь код где-нибудь.
Если вы собираетесь иметь хранимых процедур на всех (я лично их пользу, но многие этого не делают), то вы могли бы также используйте их столько, сколько вам нужно. по крайней мере, вся логика базы данных находится в одном месте. недостаток является то, что не существует, как правило, много структуры ведра с хранящимися проками.
Вашего звонком! :)
Не в то время как у вас есть разумные соглашения об именах, обновленная документация и достаточные модульные тесты для держите их организованными.
Я полагаю, что более глубокий вопрос здесь - где еще должен идти весь этот код? Представления могут использоваться для обеспечения удобного доступа к данным через стандартный SQL. Для создания SQL могут использоваться более мощные языки и библиотеки приложений. Хранимые процедуры, как правило, скрывают характер данных и вводят в систему ненужный слой абстракции, сложности и обслуживания.
С учетом возможностей инструментов реляционного сопоставления объектов для генерации базового SQL любая система, которая чрезмерно зависит от хранимых процедур, будет менее эффективной для разработки. С ORM существует намного меньше кода для написания.
Мой первый крупный проект был разработан с помощью Relation Mapper Object, который абстрагировал базу данных, поэтому мы сделали все объектно-ориентированное, и было легче проработать и исправить ошибки, и было особенно легко внести изменения, поскольку все данные и бизнес-логика был C# -кодом, однако, когда дело доходило до сложных вещей, система чувствовала себя медленной, поэтому нам пришлось обойти эти вещи или перепроектировать проект, особенно когда ORM пришлось выполнять сложные объединения в базе данных.
Im теперь работает над другой компанией, которая имеет девиз «наши приложения - это просто интерфейсы базы данных», и у нее есть свои преимущества и недостатки. У нас действительно быстрые приложения, поскольку все операции с данными выполняются на хранимых процедурах, в основном это используется SQL Server 2005, но когда дело доходит до внесения изменений или исправления для программного обеспечения, это сложнее, потому что вы должны изменить их, код C# и хранимые процедуры SQL, так что это похоже на работу дважды, вопреки тому, что я использовал ORM, у вас нет рефакторинга или строго типизированных объектов в sql, Management Studio и других инструментах много помогает, но обычно вы тратите больше времени на этот путь ,
Таким образом, я бы сказал, что это зависит от потребностей проекта, если вы не собираетесь хранить действительно сложные бизнес-данные, чем, может быть, вы даже можете вообще не использовать хранимые процедуры и использовать ORM, что упростит жизнь разработчика.Если вас беспокоит производительность и необходимо сохранить все ресурсы, кроме использования хранимых процедур, конечно, количество зависит от архитектуры, которую вы создаете, поэтому для exmaple, если у вас всегда есть хранимые процедуры для операций CRUD, вам понадобится один для вложений, один для обновления, один для удаления, один для выбора и один для листинга, так как это наиболее распространенные операции, если у вас есть 100 бизнес-объектов, умножьте их на 4 и вы получите 400 хранимых процедур только для управления наиболее основными операции на ваших объектах, так что да, их может быть слишком много.
Для меня использование множества хранимых процедур, по-видимому, приведет вас к чему-то, что эквивалентно PHP API. Тысячи глобальных функций, которые не могут иметь ничего общего с каждым, все сгруппированы вместе. Единственный способ связи между ними состоит в том, чтобы иметь какое-то соглашение об именах, где вы префикс каждой функции с именем модуля, аналогичным функциям mysql_ в PHP. Я думаю, что это очень сложно поддерживать, и очень сложно сохранить все согласованно. Я думаю, что хранимые процедуры хорошо работают для вещей, которые действительно должны иметь место на сервере. Хранимая процедура для простого запроса выбора или даже выбор запроса с соединением, вероятно, будет далеко. Используйте только хранимые процедуры, в которых на самом деле требуется передовая логика для обработки на сервере базы данных.
Полностью согласен - обслуживание тысяч SPs становится громоздким, когда происходят изменения схемы. – stephbu 2008-09-25 20:12:22
Во второй раз, эта мысль, я бы не хотел, чтобы основные тысячи процедур магазина. – 2008-09-25 20:12:55
Не существует ли риск оказаться в узлах бизнес-логики в ваших хранимых процедурах или сложно поддерживать код «спагетти», если у вас есть несколько многоцелевых sprocs? Целевые хранимые процедуры, которые выполняют только одну задачу, намного легче поддерживать. – Rob 2008-09-25 20:13:36