Pourquoi pas la réplication transactionnelle ?

changements au lieu de tout le snapshot réduirait spectaculairement
la taille des données, elle pourrait ne pas convenir à  de nombreux environnements. Ainsi, le groupe GIS (geographic information
system) municipal pour lequel je travaille, supporte une application GIS qui intègre des données géométriques de taxes
foncières avec des données d’évaluation de propriété et de permis de construire. Toutefois, la ville ne maintient pas ces données.
Ce sont deux groupes séparés dans les bureaux d’évaluation et de taxation dans chacun des trois comtés (ainsi que le Bureau of
Building de la ville) qui maintiennent les enregistrements dans différents formats. Le snapshot complet des données géométriques
se présente dans un format de fichier CAD de Microstation et le snapshot des données d’évaluation et de permis de
construire est fourni en format de fichier texte délimité. L’application GIS attend des données tabulaires provenant de SQL Server
plutôt que de ces fichiers. Donc, je dois importer les fichiers dans la base de données, transformer les données issues de différentes
sources dans un jeu de schémas unique et éliminer les doublons. De plus, comme les fichiers importés sont des snapshots
complets au lieu d’une suite de changements et parce que les transformations n’ont rien à  voir avec un mapping de un à  un, il est
trop difficile et trop coûteux en temps de suivre un jeu de changements homogène sur toutes les sources de données. Il est plus
facile et plus efficace de recharger, de transformer, et d’intégrer des jeux complets de données externes. Pour mettre ce jeu complet
de données importées à  la disposition de multiples sites, nous copions ensuite le snapshot tout entier.