Лучший подход к разработке базы данных Brownfield в SQL Server 2000/2005

Question

Я недавно приступил к разработке базы данных SQL Server 2000, которая нуждается в некоторой помощи. Мы планируем обновить его до SQL Server 2005 в ближайшее время. Эта база данных не имеет полей аудита для таблиц (CreatedBy, CreatedDate и т. Д.), Внешних ключей и ужасного общего дизайна. Есть полдюжины программ, которые напрямую обращаются к базе данных, используя встроенный SQL и другие старые / плохие методы.

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

Answer 1

Вы можете исправить, проанализировать, нормализовать и т. Д. Схему, сохраняя текущую схему / интерфейс за представлениями.

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

Таким образом, вы можете начать миграцию клиентских приложений в новую схему, позволяя текущему приложению работать. И ваши данные в новой схеме безопаснее (DRI, FK, DF, CK и т. Д.).

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

Answer 2

Возможно, вам придется начать с приложений, которые обращаются к базе данных. Скорее всего, вы обнаружите, что любые изменения в схеме базы данных сломают эти другие приложения. Наиболее распространенный виновник, который я обнаружил, это select * sql, за которым следует доступ к данным в зависимости от положения столбца. Если вы вставите столбец перед последним столбцом, этот код сломается. Кроме того, если вы не используете значения по умолчанию для новых столбцов, любые команды вставки не будут работать.

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

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