Во-первых, перестаньте пытаться думать о базах данных в объектно-ориентированных терминах. Принципы объектно-ориентированного программирования просто НЕ применяются к реляционным базам данных.
Общие базы данных - это очень хорошая вещь с точки зрения бизнеса. Несколько баз данных, хранящих информацию, которая должна быть передана между ними, быстро становятся намного сложнее, чем ваши сотни тысяч объектов. Данные, которые согласованы между корпоративными приложениями, бесценны. Попытка согласовать, если GE Corp и General Electric Corporation действительно являются одним и тем же объектом между двумя базами данных, может быть кошмаром.
Рефакторинг баз данных - хорошая цель, но в действительности она очень сложна. Не делайте этого, если у вас нет серьезной проблемы с производительностью, которую необходимо решить, или если вы не готовы посвятить себя процессу идентификации всего кода, на который может повлиять изменение. Даже тогда подумайте, можете ли вы знать весь код, который может измениться (это одна из причин, почему люди из базы данных ненавидят, ненавидят, ненавидят динамический код!).
Зачастую лучший способ рефакторинга - добавить изменения и начать переход на использование нового поля, sp и т. Д., Оставив старое на месте до истечения установленного срока действия. Поскольку вы находитесь в годовом цикле, вам нужно будет управлять этими датами в течение длительного периода времени. Чтобы увидеть, используются ли sps, вы можете определить те, в которых вы не уверены, и добавить к ним некоторый код для вставки в таблицу при каждом запуске. Если после вашего годичного цикла они не были запущены, вы можете безопасно их устранить. Цикл может быть короче в зависимости от sp.
Если я пишу что-то, что будет выполняться только ежегодно, я бы обычно вставил слово year в имя sp. Но это не может быть правдой там, где вы находитесь, однако, функция sp должна дать вам представление, если это то, что следует запускать только периодически. Я бы не ожидал, что почтовый процесс usp_send будет запускаться только один раз в год, но я могу ожидать, что usp_attendance_report может выполняться не часто. Конечно, как я уже сказал, я бы назвал это чем-то более похожим на usp_annual_attendance_report, и вы можете подумать о том, чтобы продвигаться вперед.
Но имейте в виду, что любой рефакторинг, который вы выполняете, должен проходить в течение длительного цикла, чтобы гарантировать, что вы не удалите то, что вам нужно. Если ваш код находится в системе управления исходным кодом (и все таблицы базы данных, sp, views, UDF, триггеры и т. Д. Должны быть), вы, вероятно, можете устранить некоторые вещи, зная, что в случае их сбоя вы можете довольно быстро вернуть их обратно. Опять же, я бы осмотрел объект, чтобы определить возможный риск их устранения.
Конечно, если у вас есть хорошие автоматизированные тесты, устранение чего-либо в dev и запуск тестов могут помочь вам определить, на что-то еще ссылаются.
Если вы ищете простой способ рефакторинга, я не знаю ни одного. Рефакторинг баз данных - это трудоемкий и рискованный процесс, который может не показать достаточного улучшения для тех сил, которые готовы платить за него.
Хорошая книга по рефакторингу баз данных: http://www.amazon.com/Refactoring-Databases-Evolutionary-Addison-Wesley-Signature/dp/0321293533