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

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

Я хотел бы переименовать хранимые процедуры в согласованный формат. Очевидно, что я могу переименовать их из SQL Server Management Studio, но это не будет затем обновлять вызовы, сделанные в коде сайта (С#/ASP.NET).

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

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

ОТВЕТЫ

Ответ 1

Вы можете внести изменения поэтапно:

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

Ответ 2

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

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

Ответ 3

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

Приложение

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

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

Dim SomeData as DataTable = Sprocs.sproc_GetSomeData(5)

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

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

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

Сервер Sql

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

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

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

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

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

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

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

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

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

Удачи!

Ответ 4

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

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

Ответ 5

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

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

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

Ответ 6

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

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

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

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

Ответ 7

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

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

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

Ответ 8

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

http://www.sqldigger.com/

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

Ответ 9

  • Я бы получил список ссылок на процедуру, используя следующее, потому что зависимости 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.routines имеют столбцы nvarchar (4000). Поэтому, если "mySprocName" используется в позиции 3998, оно не будет найдено. syscomments имеет несколько строк, но ROUTINES усекает. Если вы не согласны, возьмите его с gbn.
  • В соответствии с этим списком зависимостей я создам новые хранимые процедуры, начиная с хранимых процедур фонда - с наименьшими зависимостями. Но я ум не для создания хранимых процедур, с префиксом имени "sp_"
  • Убедитесь, что процедуры основания работают одинаково с существующими
  • Перейдите на следующий уровень хранимых процедур - повторите шаги 1-3 до тех пор, пока не будет обработана процедура самого высокого уровня.
  • Проверьте, что коммутатор поверх приложения использует новую процедуру - не ждите, пока все процедуры не будут обновлены для проверки взаимодействия с кодом приложения. Это не нужно делать для каждой хранимой процедуры, но ожидание этой оптовой торговли также не является отличным подходом.

Параллельно развивается и риск:

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

Ответ 10

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

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

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

Ответ 11

Меня больше беспокоит игнорирование имен процедур и замена существующего DAL с помощью блока доступа к данным Enterprise Library 5

Абоненты базы данных в корпоративной библиотеке 5 DAAB - Database.ExecuteSprocAccessor

Код, похожий на

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

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

Ответ 12

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

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

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

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

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

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

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

Ответ 13

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