Как переименовать многие хранимые процедуры, не нарушая их?

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

Это имеет небольшой штраф за производительность, и на самом деле не купит вам так много (кроме возможности "найти" ваши новые SPROCs проще)

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

Приложение

хорошая практика для будущих проектов

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

Dim SomeData as DataTable = Sprocs.sproc_GetSomeData(5)

таким образом, конец кода-это хорошо и в капсуле. Я могу пойти в Sprocs.sproc_GetSomeData и настроить имя sproc только в одном месте, и, конечно, я могу щелкнуть правой кнопкой мыши по методу и сделать символическое переименование, чтобы исправить вызов метода в масштабе решения.

без забора

без этой абстракции вы можете просто найти в файлах (Cntl+Shift+F) имя sproc, а затем, если результаты выглядят правильно, откройте файлы и найдите/замените все вхождения.

в Sql Server

Не доверяйте зависимостям просмотра

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

просмотр зависимостей больно мне, и для этого потребуется время. :)

Оберните Его!

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

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

наконец, когда вы уверены, что старый sproc не используется, удалите его.

Других Областях?

может быть много других областей, а также. На ум приходят службы Reporting Services. пакет служб SSIS. Использование техники сохранения старого sproc вокруг и перенаправление на новый (упомянутый выше) поможет вам узнать, если вы что-то пропустили, однако он не скажет вам что вы пропустили. Это может привести к большой боли!

хорошее удачи!

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

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

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

когда приложению необходимо вызвать хранимый proc, имя определяется из web.конфиг.

Это упрощает управление всеми потенциальными вызовами, которые приложение может сделать на уровне служб баз данных.

это будет немного утомительный поиск через исходный код и другие объекты базы данных, которые я боюсь.

Не забудьте пакеты служб SSIS, задания агента SQL, службы Reporting Services rdl, а также основной код приложения.

вы можете использовать регулярное выражение, например spProc1|spProc2 для поиска в исходном коде всех имен объектов одновременно, если у вас есть инструмент, поддерживающий поиск по файлам с использованием регулярных выражений (я использовал RegexBuddy для этого в прошлое)

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

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

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

есть инструменты для VS, которые могут управлять изменением имени, например рефакторинг и resharper

Я сделал это, и я сильно полагался на глобальный поиск в моем исходном коде для имен хранимых процедур и SQL digger, чтобы найти SQL procs, которые называются sql proces.

http://www.sqldigger.com/

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

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

   SELECT OBJECT_NAME(m.object_id), m.*
     FROM SYS.SQL_MODULES m
    WHERE m.definition LIKE N'%my_sproc_name%'
   

   • SQL должен запускаться в каждой базе данных, где могут быть ссылки.
   • syscomments и INFORMATION_SCHEMA.подпрограммы имеют столбцы nvarchar(4000). Поэтому, если "mySprocName" используется в позиции 3998, он не будет найден. syscomments есть несколько строк, но процедуры усекают. если вы не согласны, возьмите его с gbn.
2. на основе этого списка зависимостей я бы создал новые хранимые процедуры, начиная с хранимых процедур foundation - с наименьшими зависимостями. Но я бы ... --15-->ум не чтобы создать хранимые процедуры, добавьте к имени префикс "sp_"
3. убедитесь, что процедуры foundation работают идентично существующим одни!--7-->
4. переход на следующий уровень хранимых процедур-повторите шаги 1-3 по мере необходимости, пока не будет обработана процедура самого высокого уровня.
5. протестируйте переключатель, используемый приложением для новой процедуры - не ждите обновления всех процедур для тестирования взаимодействия с кодом приложения. Это не нужно делать для каждой хранимой процедуры, но ждать, чтобы сделать это оптом, тоже не большой подход.

развиваются параллельно и это тоже риски:

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

используйте утилиту типа FileSeek для поиска содержимого внутри каждого файла в папке проекта. Не доверяйте поиску windows-он медленный и недружелюбный.

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

Это может быть очень трудоемким и повторяющимся для больших систем.

меня больше беспокоит игнорирование имен процедур и замена устаревшего DAL на Enterprise Library Data Access Block 5

методы доступа к базе данных в корпоративной библиотеке 5 DAAB-Database.Методы executesprocaccessor

имея код, который похож на

 public Contact FetchById(int id)
 {
  return _database.ExecuteSprocAccessor<Contact>
   ("FetchContactById", id).SingleOrDefault();
 }

будет иметь по крайней мере в миллиард раз больше значения, чем при сохранении процессов с согласованными именами, особенно если текущий код передает Таблицы данных или наборы данных :: shudders::

Я все за рефакторинг любого кода.

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

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

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

Взгляните на DBSourceTools. http://dbsourcetools.codeplex.com
Он специально разработан, чтобы помочь разработчикам получить свои базы данных под контролем исходного кода.

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

Однажды вы приняли это мышление, эта гигантская и подверженная ошибкам задача станет простой.

предполагается, что вы используете SQL Server 2005 или выше. Вариант, который я использовал раньше, - переименовать старый объект базы данных и создать синоним SQL Server со старым именем. Это позволит вам обновить объекты до любого соглашения, которое вы выберете, и заменить рефрены в коде, пакетах служб SSIS и т. д... как вы идете по ним. Затем вы можете сконцентрироваться на обновлении ссылок в коде постепенно, однако вы выбираете версии обслуживания (в отличие от их разрыва все сразу). Поскольку вы чувствуете, что нашли все ссылки, вы можете удалить синоним, поскольку код идет в QA.