Как мне подойти к переносу данных из «плохого» дизайна базы данных в пригодный для использования дизайн?

Question

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

Пример: в таблице Project есть имя клиента (среди других значений), а также таблица клиентов, которая просто содержит имена клиентов [нигде нет ключей]. Таблица клиентов просто используется как пул значений, предлагаемых пользователю при добавлении нового проекта. В таблице клиентов нет ни первичного ключа, ни внешнего ключа.

«Шаблоны проектирования», такие как это, распространены в текущем состоянии базы данных и в приложениях, которые ее используют. Инструменты, которыми я располагаю, это SQL Server 2005, SQL Server Management Studio и Visual Studio 2008. Мой первоначальный подход состоял в том, чтобы вручную определить, какая информация нуждается в нормализации, и выполнить запросы Select INTO. Есть ли лучший подход, чем в каждом конкретном случае, или в любом случае это может быть автоматизировано?

Edit: Кроме того, я обнаружил, что «номер рабочего задания» не является полем IDENTITY (autonumber, unique), и они генерируются последовательно и уникальны для каждого рабочего задания. Есть также некоторые пробелы в существующей нумерации, но все они уникальны. Является ли лучший подход для написания процедуры хранения для создания фиктивных строк перед миграцией?

Answer 1

Лучший подход к переходу на удобный дизайн? ВНИМАТЕЛЬНО

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

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

Некоторые практические мысли ...

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

Автоматизировать Автоматизировать Автоматизировать ... Никогда не вносите изменения в производственную систему "вживую" с помощью SQL Server Management Studio. Написание сценариев SQL, которые выполняют все изменения за один раз; разработайте и протестируйте их на копии базы данных, чтобы убедиться, что вы правильно поняли. Не используйте производство в качестве тестового сервера - вы можете случайно запустить скрипт против производства; используйте выделенный тестовый сервер (если размер базы данных меньше 4 ГБ, используйте SQL Server Express, работающий на собственной машине).

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

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

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

Удачи!

Answer 2

Просто чтобы добавить простую подсказку. Когда у вас есть диаграмма Entity Relationship на одном из A4 или A3 перед вами, правильная нормализация будет означать не много-много отношений. Проверьте эту книгу или хотя бы сайт также.

Answer 3

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

http://en.wikipedia.org/wiki/SQL_Server_Integration_Services http://www.microsoft.com/sqlserver/2005/en/us/integration-services.aspx

Answer 4

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

В любом случае, я бы

• дизайн новой схемы
• записывает пакеты T-SQL, используя курсоры, где это необходимо, для переноса данных

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

Answer 5

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

В частности:

1. Один за другим замените запросы, используемые в коде, хранимыми процедурами. Как часть замены, напишите модуль (или интеграцию) непосредственно для тестирования хранимых процедур. Рассмотрим вспомогательный класс уровня StoredProcs для консолидации доступа к базе данных.
2. После того как все запросы являются sprocs, вы можете реорганизовать базу данных, используя эти модульные тесты, чтобы убедиться, что вы не меняете ожидаемое поведение.
3. Дополнительное преимущество: у вас будут эти юнит-тесты для защиты от будущих поломок.

Answer 6

1. Создайте новую базу данных так, как вы думаете, она должна быть структурирована.
2. Создать таблицу importError в новой базе данных с такими столбцами, как «oldId» и «errorDesc»
3. Напишите простой, процедурный, разборчивый скрипт, который пытается выбрать строку из старой структуры и вставить ее в новую структуру. Если вставка не удалась, зарегистрируйте как можно более конкретную ошибку в таблице importError (в частности, , почему вставка не удалась).
4. Запустите скрипт.
5. Проверить новые данные. Проверьте, нет ли ошибок, зарегистрированных в таблице importError. Если данные недействительны или имеются ошибки, выполните рефакторинг сценария и запустите его снова, возможно, при необходимости изменив новую структуру базы данных.
6. Повторяйте шаги 1-5, пока у вас не будет твердого сценария преобразования.

Результатом этого процесса будет то, что у вас есть: а) новая структура БД, которая проверена на соответствие старой структуре и проверена на «прагматизм»; b) журнал потенциальных проблем, с которыми вам может потребоваться код (например, ошибки, которые вы не можете исправить с помощью конверсии, поскольку они требуют уступки в вашей схеме, которая вам не нужна)

(Могу заметить, что полезно писать скрипт на выбранном вами языке сценариев / программирования, а не, скажем, на SQL.)

Answer 7

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

Повторный номер заказа на работу; предполагая, что вы хотите, чтобы это продолжало быть столбцом IDENTITY; Вы можете заполнить данные, найти самые большие, а затем использовать ALTER TABLE, чтобы сделать их IDENTITY? У меня нет инструментов TSQL, поэтому, к сожалению, я не могу тестировать. В качестве альтернативы, просто рассмотрите это естественный ключ .