У вас может быть слишком много хранимых процедур?
Есть ли такая вещь, как слишком много хранимых процедур?
Я знаю, что нет предела количеству, которое вы можете иметь, но это какая-то производительность или архитектурная причина не создавать сотни, тысячи??
19 ответов
Для меня самое большое ограничение в том, что сотни или тысячи хранилищ - это ремонтопригодность. Даже если это не прямой удар по производительности, это должно быть соображение. Это архитектурная точка зрения, вы должны планировать не только начальную разработку приложения, но и будущие изменения и обслуживание.
При этом вы должны проектировать / создавать столько, сколько требует ваше приложение. Хотя с Hibernate, NHibernate, .NET LINQ я бы постарался сохранить как можно больше логики процедур хранения в коде и помещать ее в базу данных только тогда, когда скорость является фактором.
Я хотел бы только упомянуть, что со всеми такими вещами обслуживание становится проблемой. Кто знает, что они все и для чего они служат? Что происходит годами, когда они являются просто артефактами унаследованной системы, которую никто не может вспомнить, для чего они предназначены, но боится связываться с ними?
Я думаю, что главное - это вопрос, возможно ли это, но должно ли это быть сделано. Это всего лишь одна мысль в любом случае.
У меня чуть меньше 200 в моем коммерческом продукте SQL Server 2005, который, вероятно, увеличится еще на 10-20 в следующие несколько дней для некоторых новых отчетов.
Там, где это возможно, я пишу "подпрограммы" sprocs, так что в любое время, когда я обнаруживаю, что собираю 3 или 4 одинаковых утверждения в более чем пару sprocs, пришло время превратить эти несколько утверждений в подпрограмму, если вы понимаете, что я имею в виду.
Я не склонен использовать sprocs для выполнения всей бизнес-логики как таковой, я просто предпочитаю, чтобы sprocs делал все, что можно было бы рассматривать как "транзакционный" - так, где мой клиентский код (в Delphi, но неважно) мог бы выполнить нечетная вставка или само обновление, как только что-то требует обновления или вставки нескольких вещей "сразу", наступает время для sproc.
У меня есть простое, грубое соглашение об именах, чтобы помочь в удобочитаемости (и в обслуживании!)
Кодовое название продукта - "Рейчел", поэтому мы имеем
RP_wh независимо - это обычные спроки, которые обновляют / вставляют данные,
- или вернуть небольшие наборы результатов
RXP_wh независимо - это подпрограммы sprocs, которые работают как "функции"
- или рабочие к процессам типа RP_
REP_whither - это спрэки, которые просто действуют как прославленные взгляды почти
- они не изменяют данные, они возвращают потенциально сложные наборы результатов
- для целей отчетности и т. д.
XX_whither - это внутренние тесты / разработки / обслуживания
- что клиентское приложение (или локальный dba) обычно не использует
наименование является произвольным, оно просто помогает отличить префикс sp_, используемый SQL Server.
Я думаю, если бы я обнаружил, что у меня было 400-500 sprocs в базе данных, я мог бы обеспокоиться, но несколько сотен не проблема вообще, если у вас есть система для определения того, за какую деятельность отвечает каждый sproc. Я предпочел бы отследить изменения схемы в нескольких сотнях строк (где инструменты SQL Server могут помочь вам найти зависимости и т. Д.), Чем пытаться отследить изменения схемы в моем языке программирования высокого уровня.
Вы имеете в виду, помимо того, что вам нужно поддерживать их все, когда вы вносите изменения в базу данных? Это большая причина для меня. Лучше иметь меньше таких, которые могут справиться со многими сценариями, чем сотни, которые могут справиться только с одним.
Я предполагаю, что более глубокий вопрос здесь - куда еще должен идти весь этот код? Представления могут использоваться для обеспечения удобного доступа к данным через стандартный SQL. Более мощные языки приложений и библиотеки могут использоваться для генерации SQL. Хранимые процедуры имеют тенденцию затенять природу данных и вводить ненужный уровень абстракции, сложности и обслуживания в систему.
Учитывая возможности инструментов реляционного отображения объектов для генерации базового SQL, любая система, которая чрезмерно зависит от хранимых процедур, будет менее эффективной для разработки. С ORM кода для написания гораздо меньше.
Черт возьми, вы можете иметь слишком много. Пару лет назад я работал над системой, в которой было около 10000 процедур. Это было безумно. Люди, которые писали систему, на самом деле не знали, как программировать, но они знали, как исправить плохо структурированные процессы, поэтому они включили почти всю логику приложения в процессы. Некоторые из проков бежали за тысячи строк. Управление беспорядком было кошмаром.
Слишком много (и я не могу нарисовать вам конкретную линию на песке), вероятно, является показателем плохого дизайна. Кроме того, как отмечали другие, существуют более эффективные способы создания детализированного интерфейса базы данных, не прибегая к огромному количеству процедур.
Мой вопрос: почему вы не используете какую-то промежуточную платформу, если говорите о сотнях или тысячах хранимых процедур?
Назовите меня старомодным, но я подумал, что база данных должна просто содержать данные, и программы должны принимать решения бизнес-логики.
Слишком много любой конкретной вещи, вероятно, означает, что вы делаете это неправильно. Слишком много конфигурационных файлов, слишком много кнопок на экране...
Не могу говорить о других РСУБД, но приложение Oracle, использующее PL/SQL, должно логически объединять процедуры и функции в пакеты, чтобы предотвратить каскадные аннулирования и лучше управлять кодом.
Мне кажется, что использование большого количества хранимых процедур ведет вас к чему-то эквивалентному PHP API. Тысячи глобальных функций, которые могут не иметь ничего общего друг с другом, сгруппированы вместе. Единственный способ связать их между собой - это иметь какое-то соглашение об именах, в котором перед каждой функцией ставится префикс имени модуля, аналогично функциям mysql_ в PHP. Я думаю, что это очень трудно поддерживать, и очень трудно поддерживать постоянство всего. Я думаю, что хранимые процедуры хорошо работают для вещей, которые действительно должны иметь место на сервере. Хранимая процедура для простого запроса выбора или даже запроса выбора с объединением, вероятно, зашла далеко. Используйте хранимые процедуры только в тех случаях, когда вам требуется обработка расширенной логики на сервере базы данных.
В базе данных Oracle вы можете использовать пакеты для группировки связанных процедур.
некоторые из них и ваше пространство имен освободятся.
Нет, пока у вас есть разумные соглашения об именах, актуальная документация и достаточно модульных тестов, чтобы держать их организованными.
Мой первый большой проект был разработан с использованием Object Relational Mapper, который абстрагировал базу данных, поэтому мы делали все объектно-ориентированным, и было проще обслуживать и исправлять ошибки, и было особенно легко вносить изменения, поскольку весь доступ к данным и бизнес-логике был C# -кодом, однако, когда дело дошло до сложных задач, система чувствовала себя медленной, поэтому нам пришлось обойти эти вещи или перестроить проект, особенно когда ORM пришлось делать сложные объединения в базе данных.
Сейчас я работаю в другой компании, у которой есть девиз: "наши приложения - это только внешние стороны базы данных", и у нее есть свои преимущества и недостатки. У нас действительно быстрые приложения, поскольку все операции с данными выполняются над хранимыми процедурами, в основном это SQL Server 2005, но когда дело доходит до внесения изменений или исправления в программном обеспечении, становится сложнее, потому что вам приходится менять оба, код на C# и хранимые процедуры SQL, так что все равно, что работать дважды, в отличие от того, когда я использовал ORM, у вас нет рефакторинга или строго типизированных объектов в SQL, Management Studio и других инструментах очень помогают, но обычно вы тратите больше времени на это,
Так что я бы сказал, что это зависит от потребностей проекта, если вы не собираетесь хранить действительно сложные бизнес-данные, чем, возможно, вы могли бы вообще избежать использования хранимых процедур и использовать ORM, который облегчает жизнь разработчика. Если вы беспокоитесь о производительности и хотите сохранить все ресурсы, чем следует использовать хранимые процедуры, то, конечно, их количество зависит от архитектуры, которую вы проектируете, поэтому, например, если у вас всегда есть хранимые процедуры для операций CRUD, вам потребуется для вставок, один для обновления, один для удаления, один для выбора и один для листинга, так как это наиболее распространенные операции, если у вас есть 100 бизнес-объектов, умножьте эти 4 на это, и вы получите 400 хранимых процедур, чтобы просто управлять самыми основными операций над вашими объектами, так что да, их может быть слишком много.
Нет, не то, что я знаю. Тем не менее, вы должны иметь хорошее соглашение об именах для них. Например, начинать их с usp_ это то, что многие люди любят делать (быстрее, чем начинать с sp_).
Возможно, вашими отчетными sprocs должны быть usp_reporting_, а вашими бизнес-объектами должны быть usp_bussiness_ и т. Д. Пока вы можете ими управлять, не должно быть проблем с их большим количеством.
Если они становятся слишком большими, вы можете разделить базу данных на несколько баз данных. Это может иметь более логичный смысл и может помочь с размером базы данных и тому подобным.
Если у вас много хранимых процедур, вы обнаружите, что привязываете себя к одной базе данных - некоторые из них не могут быть легко перенесены.
Привязка себя к одной базе данных не является хорошим дизайном.
Более того, если у вас есть бизнес-логика в базе данных и на бизнес-уровне, то обслуживание становится проблемой.
Как уже говорили другие, это действительно сводится к аспекту управления. Через некоторое время он превращается в нахождение иголки в стоге сена. Это тем более, когда существуют плохие стандарты именования...
Да, вы можете иметь слишком много хранимых процедур.
Соглашения об именах могут действительно помочь с этим. Например, если у вас есть соглашение об именах, где у вас всегда есть имя таблицы и InsUpd или Get, довольно легко найти правильную хранимую процедуру, когда вам это нужно. Если у вас нет какого-то стандартного соглашения об именах, было бы очень легко придумать две (или более) процедуры, которые делают почти одно и то же.
Было бы легко найти пару следующих пунктов без стандартизированного соглашения об именах... usp_GetCustomersOrder, CustomerOrderGet_sp, GetOrdersByCustomer_sp, spOrderDetailFetch, GetCustOrderInfo и т. Д.
Еще одна вещь, которая начинает происходить, когда у вас много хранимых процедур, это то, что у вас будут некоторые хранимые процедуры, которые никогда не используются, а некоторые просто используются редко... Если у вас нет способа отслеживать использование хранимых процедур, вы Вы либо получите много неиспользованных процедур... или, что еще хуже, избавитесь от процедуры, которая, по вашему мнению, никогда не используется, и узнаете впоследствии, что она используется только один раз в год или раз в квартал.:(
Джефф
Я думаю, что пока вы называете их uspXXX, а не spXXX, поиск по имени будет прямым, так что никаких минусов - хотя вы можете подумать об обобщении процедур, если у вас есть тысячи...
Вы должны поместить весь этот код куда-нибудь.
Если вы собираетесь использовать хранимые процедуры вообще (я лично одобряю их, но многие этого не делают), то вы можете использовать их столько, сколько вам нужно. По крайней мере, вся логика базы данных находится в одном месте. Недостатком является то, что структура, заполненная хранимыми процессами, не имеет большой структуры.
Ваш звонок!:)