У меня чуть меньше 200 в моем коммерческом продукте SQL Server 2005, который, вероятно, увеличится еще на 10-20 в следующие несколько дней для некоторых новых отчетов.
Там, где это возможно, я пишу «подпрограммы» sprocs, чтобы каждый раз, когда я обнаруживал, что собираю 3 или 4 одинаковых утверждения в более чем пару sprocs, пришло время превратить эти несколько утверждений в подпрограмму, если вы понимаете, что я имею в виду .
Я не склонен использовать sprocs для выполнения всей бизнес-логики как таковой, я просто предпочитаю, чтобы sprocs выполнял все, что можно было бы считать «транзакционным» - так, где мой клиентский код (в Delphi, но неважно) может сделать нечетную вставку или обновить себя, как только что-то потребует обновления или вставки нескольких вещей «сразу», пришло время для sproc.
У меня есть простое, грубое соглашение об именах, чтобы помочь в удобочитаемости (и в обслуживании!)
Кодовое название продукта 'Rachel', поэтому у нас есть
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 спроков, меня это может заинтересовать, но несколько сотен не проблема, если у вас есть система для определения того, за какую деятельность отвечает каждый спрок. за. Я предпочел бы отследить изменения схемы в нескольких сотнях шагов (где инструменты SQL Server могут помочь вам найти зависимости и т. Д.), Чем пытаться отследить изменения схемы в моем языке программирования высокого уровня.