Использование DTO Pattern для синхронизации двух схем?

Question

Мне нужно синхронизировать две базы данных. Эти базы данных хранят одни и те же семантические объекты, но физически различаются в двух базах данных.

Я планирую использовать шаблон DTO для унификации представления объекта:

DB ----> DTO ----> MAPPING (Getter / Setters) ----> DTO ----> DB

Я думаю, что это лучшая идея, чем физическая синхронизация с использованием SQL-запросов на каждой стороне, я использую hibernate для добавления абстракции и синхронизации объектов.

Как вы думаете, это хорошая идея?

Answer 1

Хорошая ссылка выше на Руководство автостопщика.

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

Посмотрите на инструменты ETL. Я не знаком с инструментами, доступными в сообществе открытого исходного кода, но если вы склонитесь в этом направлении, я уверен, что вы найдете некоторые. Другие инструменты, на которые вы можете обратить внимание: Informatica, Data Integrator, SQL Server Integration Services и, если вы имеете дело с пространственными данными, есть еще один, называемый Alteryx.

Тим

Answer 2

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

Answer 3

Выполнение этого с помощью ORM может быть на порядок медленнее, чем хорошо разработанный сценарий SQL. Это зависит от размера БД.

EDIT

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

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

1. Для схем, которые только незначительно отличаются (например, имена или простое преобразование значений столбцов), я бы выбрал сценарий SQL. Это, вероятно, более компактный и простой в использовании и общении.

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

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

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

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

Решение за вами.