Может у вас слишком много хранимых процедур?

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

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

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

При этом вы должны спроектировать / создать столько, сколько требуется вашему приложению. Хотя с Hibernate, NHibernate, .NET LINQ я бы попытался сохранить как можно больше логики процедур хранения в коде и помещать ее в базу данных только тогда, когда скорость является фактором.

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

Думаю, главное - вопрос не в том, возможно ли это, а в том, нужно ли это делать. В любом случае, это всего лишь одна мысль.

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

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

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

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

Может быть, ваши отчетные sprocs должны быть usp_reporting_, а ваши бизнес-объекты должны быть usp_bussiness_ и т. д. Пока вы можете ими управлять, не должно быть проблем с их большим количеством.

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

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

Привязка себя к одной базе данных - плохой дизайн.

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

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

некоторые из них и ваше пространство имен освободятся.

Черт возьми, у тебя может быть слишком много. Пару лет назад я работал над системой, в которой было около 10 000 процессов. Это было безумие. Люди, которые писали систему, на самом деле не знали, как программировать, но они знали, как исправлять плохо структурированные процессы, поэтому они поместили почти всю логику приложения в процессы. Некоторые процессы выполнялись для тысяч строк. Управление беспорядком было кошмаром.

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

У меня чуть меньше 200 в моем коммерческом продукте SQL Server 2005, который, вероятно, увеличится еще примерно на 10-20 в следующие несколько дней для некоторых новых отчетов.

По возможности я пишу sprocs «подпрограммы», так что всякий раз, когда я обнаруживаю, что объединяю 3 или 4 идентичных оператора в более чем пару sproc, пора превратить эти несколько операторов в подпрограмму, если вы понимаете, что я имею в виду.

Я не склонен использовать 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 sproc, я мог бы забеспокоиться, но несколько сотен вообще не проблема, если у вас есть система для определения того, за какой вид деятельности отвечает каждый sproc. Я бы предпочел отследить изменения схемы в нескольких сотнях sprocs (где инструменты SQL Server могут помочь вам найти зависимости и т. д.), Чем пытаться отследить изменения схемы на моем языке программирования высокого уровня.

Да, ты можешь.

Если у вас больше нуля, у вас слишком много

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

Ничего не могу сказать о других СУБД, но приложение Oracle, использующее PL / SQL, должно логически объединять процедуры и функции в пакеты, чтобы предотвратить каскадную недействительность и лучше управлять кодом.

Да, у вас может быть слишком много хранимых процедур.

Соглашения об именах действительно могут помочь в этом. Например, если у вас есть соглашение об именах, где у вас всегда есть имя таблицы и InsUpd или Get, довольно легко найти хранимую процедуру Правильно, когда она вам нужна. Если у вас нет какого-либо стандартного соглашения об именах, было бы очень легко придумать две (или более) процедуры, которые делают почти одно и то же.

Было бы легко найти пару из следующих, не имея стандартизированного соглашения об именах ... usp_GetCustomersOrder, CustomerOrderGet_sp, GetOrdersByCustomer_sp, spOrderDetailFetch, GetCustOrderInfo и т. д.

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

Джефф

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

Ваш звонок! :)

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

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

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

Мой первый большой проект был разработан с помощью Object Relational Mapper, который абстрагировал базу данных, поэтому мы сделали все объектно-ориентированным, и было проще отслеживать и исправлять ошибки, и было особенно легко вносить изменения, поскольку весь доступ к данным и бизнес-логика были кодом C#, однако, когда дело доходило до сложных вещей, система казалась медленной, поэтому нам приходилось работать над этими вещами или переделывать проект, особенно когда ORM приходилось выполнять сложные соединения в базе данных.

Сейчас я работаю в другой компании, девиз которой: «наши приложения - это просто внешние интерфейсы базы данных», и у нее есть свои преимущества и недостатки. У нас есть действительно быстрые приложения, поскольку все операции с данными выполняются с хранимыми процедурами, в основном это используется SQL Server 2005, но когда дело доходит до внесения изменений или исправлений в программное обеспечение, это сложнее, потому что вам нужно изменить и то, и другое, код C# и хранимые процедуры SQL, так что это похоже на двойную работу, в отличие от того, когда я использовал ORM, у вас нет рефакторинга или строго типизированных объектов в sql, Management Studio и другие инструменты очень помогают, но обычно вы тратите больше времени, идя таким образом .

Поэтому я бы сказал, что в зависимости от потребностей проекта, если вы не собираетесь хранить действительно сложные бизнес-данные, возможно, вы вообще могли бы вообще отказаться от использования хранимых процедур и использовать ORM, который упрощает жизнь разработчика. Если вас беспокоит производительность и вам нужно сохранить все ресурсы, чем вы должны использовать хранимые процедуры, конечно, количество зависит от архитектуры, которую вы разрабатываете, поэтому, например, если у вас всегда есть хранимые процедуры для операций CRUD, вам понадобится одна для вставок, один для обновления, один для удаления, один для выбора и один для перечисления, поскольку это наиболее распространенные операции, если у вас 100 бизнес-объектов, умножьте эти 4 на это, и вы получите 400 хранимых процедур только для управления самыми основными операции над вашими объектами, так что да, их может быть слишком много.

Мне кажется, что использование большого количества хранимых процедур ведет к чему-то эквивалентному PHP API. Тысячи глобальных функций, которые могут не иметь ничего общего друг с другом, сгруппированы вместе. Единственный способ установить связь между ними - это иметь какое-то соглашение об именах, в котором вы добавляете каждой функции префикс имени модуля, аналогично функциям mysql_ в PHP. Я думаю, что это очень сложно поддерживать, и очень сложно поддерживать все согласованно. Я считаю, что хранимые процедуры хорошо подходят для вещей, которые действительно должны выполняться на сервере. Хранимая процедура для простого запроса выбора или даже запроса выбора с соединением, вероятно, зайдет слишком далеко. Используйте хранимые процедуры только там, где вам действительно требуется обработка расширенной логики на сервере базы данных.