Utiliser le modèle DTO pour synchroniser deux schémas?

Question

J'ai besoin de synchroniser deux bases de données. Ces bases de données stockent les mêmes objets sémantiques mais physiquement différents entre deux bases de données.

je prévois d'utiliser un motif de DTO pour uniformiser la représentation de l'objet:

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

Je pense que c'est une meilleure idée que de synchroniser physiquement en utilisant SQL Query de chaque côté, j'utilise hibernate pour ajouter de l'abstraction, et synchroniser l'objet.

Pensez-vous que c'est une bonne idée?

Answer 1

Faire cela avec un ORM pourrait être plus lent par ordre de grandeur qu'un script SQL bien conçu. Cela dépend de la taille de la base de données.

EDIT

Je voudrais ajouter que la décision devrait dépendre du montant des différences entre les deux schémas, pas votre expertise avec SQL. SQL est si courant que les développeurs devraient être capables d'écrire du script simple d'une manière propre. SQL a également l'avantage que tout le monde sait comment exécuter le script, mais tout le monde ne saura pas comment exécuter votre outil personnalisé (c'est un problème que j'ai rencontré dans la pratique si la migration est effectivement effectuée par quelqu'un d'autre).

1. Pour les schémas qui ne diffèrent légèrement (par exemple des noms, ou la simple transformation des valeurs de la colonne), je pencherais pour un script SQL. C'est probablement plus compact et simple à utiliser et à communiquer. Pour les schémas avec différences importantes, avec des données organisées dans différentes tables ou logique complexe pour mapper une valeur d'un schéma à l'autre, puis un outil dédié peut avoir un sens. Les chances sont que l'effort initial pour écrire l'outil est plus important, mais il peut être un atout une fois créé.

Vous devriez également considérer aspects non fonctionnels tels que la gestion des exceptions, la consignation des erreurs, le travail de fractionnement dans la transaction plus petite (parce qu'il ya trop de données), etc.

1. Le script SQL peut en effet devenir "désordonné" dans de telles conditions. Si vous avez de telles contraintes, SQL nécessitera des compétences avancées et aura tendance à être difficile à utiliser et à maintenir.

2. L'outil personnalisé peut évoluer vers un mini-ETL avec la possibilité de découper le travail dans de petites transactions, de gérer et d'enregistrer les erreurs, etc. Ceci est plus de travail et peut devenir un projet dédié.

La décision est à vous.

Answer 2

Je l'ai déjà fait, et je pensais que c'était une façon assez simple et directe de faire le lien entre 2 DB. Le seul inconvénient est que chaque fois que la base de données change, j'ai dû mettre à jour la logique de mappage, mais c'est généralement assez simple à faire.

Answer 3

Belle référence ci-dessus au guide de l'auto-stoppeur.

Mes deux cents. Vous devez envisager d'utiliser le bon outil pour le travail. Bien qu'il soit impératif d'écrire du code personnalisé pour résoudre ce problème, il existe de nombreux outils qui le font déjà pour vous, mapper la source à la cible, effectuer des transformations personnalisées d'attributs en attributs et livrer plus rapidement.

Regardez les outils ETL. Je ne suis pas familier avec les outils disponibles dans la communauté open source, mais si vous vous penchez dans cette direction, je suis sûr que vous en trouverez. D'autres outils que vous pouvez consulter sont: Informatica, Data Integrator, Services d'intégration SQL Server et si vous traitez des données spatiales, il y en a un autre appelé Alteryx. Je ne comprends pas "mêmes objets sémantiques mais physiquement différents"