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

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

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

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

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

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

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

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

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

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

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

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

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

http://www.sqldigger.com/

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

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

    ВЫБРАТЬ ИМЯ ОБЪЕКТА (m.object_id), m. *
   ИЗ SYS.SQL_MODULES m
   ГДЕ m.definition LIKE N '% my_sproc_name%'
   

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

Параллельная разработка также сопряжена с риском:

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

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

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

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

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

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

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

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

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

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

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

Приложение

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

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

Dim SomeData as DataTable = Sprocs.sproc_GetSomeData(5)

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

Без абстракции

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

Sql Server

Не доверяйте View Dependencies

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

View Dependencies ранили меня, и потребуется время, чтобы это зажило. :)

Wrap It!

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

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

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

Другие области?

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

Удачи!

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

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

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

Database Accessors in Enterprise Library 5 DAAB - Database.ExecuteSprocAccessor

Наличие кода, похожего на

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

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

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

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

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