Существуют ли инструменты для сравнения данных двух разных схем?

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

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

Есть ли инструменты, которые могли бы помочь в этом типе сравнения?

Если нет, то есть ли какие-нибудь библиотеки / фреймворки, которые могли бы помочь начать разработку собственного решения?

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

Мой солутон: я сравниваю два набора данных, создавая VIEWкаждую таблицу в старой базе данных с теми же полями, что и в новой таблице базы данных.

Затем я сравниваю данные, используя методику, описанную здесь: Самый короткий, быстрый и простой способ сравнения двух таблиц в SQL Server: UNION!

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

В UNIONсравнении показывает мне только строки с различиями, так как только данные верны , я получаю пустой результирующий набор.

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

Важное замечание: Это согласование не о том, чтобы убедиться, что место назначения точно соответствует источнику в контексте данных (есть причина, по которой вы переходите на новую систему), но вам нужно объяснить любые расхождения!

Основа:

1. Определите метрики, которые вы будете использовать для измерения (т. Е. Общее число пользователей, сумма всех их возрастов, список идентификаторов пользователей и их почтовые индексы ...). Я пытаюсь использовать несколько метрик из: итоговых, средних и выборочных / подробных записей.
2. Сбросить эти данные в общее место (через представления / отчеты / все, что разумно)
3. Сравните ваши данные и убедитесь, что любое расхождение можно объяснить

Я обычно делю сравнение на несколько методов (в частности, для детальных метрик):

• По таблицам: обычно используя исходную таблицу в качестве определения, создавая набор представлений в целевой БД, чтобы попытаться воспроизвести данные исходной таблицы
• По объектам: в зависимости от БД и того, что вы храните, может иметь смысл создать целостное представление объектов (т. Е. Пользователя) по нескольким таблицам, аналогично описанному выше созданию набора представлений для возврата этого объекта в виде набор результатов
• По отчетам: если исходная база данных имеет хороший всеобъемлющий набор отчетов управления, другой способ - воспроизвести эти отчеты с точно таким же форматированием

Техники:

Независимо от того, какой метод я использовал для создания того, что будет сравниваться, я получаю набор файлов / views / dbs, в которых содержатся сопоставимые данные источника и назначения, затем в зависимости от носителя я могу использовать один из общедоступных инструментов. сравнить их. Мои собственные предпочтения:

1. Сравнение файлов
   Создайте две разные папки для SourceDB и DestinationDB (отметка время / версия, чтобы я знал, когда я выполнял сверку) и выгрузите выходные данные моих метрик в файлы с соответствующим именем, а затем используйте инструмент сравнения (например, CSDiff ) для выявления различий

2. Сравнение Excel.
   В частности, при работе с отчетами управления я создам набор книг Excel для сравнения отчетов (по сути, используя VLookups и сравнивая итоги).

3. Сравнение данных
   Вместо того, чтобы выводить данные сверки в файлы или отчеты, выведите их в отдельные БД, а затем используйте что-то вроде Redgate SQL Data Compare для сравнения БД.

Другие инструменты:

Не пробовал ничего из этого, но быстрый поиск в Google по «Инструментам согласования данных» дает:

• ПО для сверки данных n-Tierfs
• Проверка сверки данных производительности

Есть и другие, но это были те, которые выглядели разумно

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

• Что если таблица была разбита или объединена и т. Д.?
• Что, если у вас было datetime, теперь у вас smalldatetime = данные будут другими
• ...

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

Только вы знаете, что вы изменили или изменили

Вам будет невозможно сравнивать разные схемы. Чтобы решить вашу проблему, я бы выяснил, какие данные вам нужно сравнить. Затем я бы создал представление на каждом сервере, которое будет извлекать данные, которые я хотел сравнить (с учетом типов данных и тому подобное).

Когда оба представления совпадают, я бы использовал сторонний инструмент, такой как Red Gate Data Compare, чтобы увидеть, какие строки отличаются.

Звучит как боль. Удачи!

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

www.sql-server-tool.com

• Одна лицензия стоит 99 $, но вы можете попробовать ее бесплатно в течение 30 дней.

Программа, названная SCT для «средства сравнения SQL Server» (я никогда не умела называть вещи :), имеет множество опций тонкой настройки, таких как: игнорирование выбранных столбцов или указание метода сравнения (запись за записью или первичный ключ / сравнение индекса). Сравнительные «сессии» могут быть сохранены и воспроизведены позже без необходимости повторного ввода параметров. Параметр командной строки можно использовать для полной автоматизации сравнений.

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

Дариуш Дзевиалтовски-Гинтовт