Tout ce que vous suggérez est une recette pour la douleur et les migrations ratées. Les gens diront et diront à quel point PostgreSQL est affreux, lent et peu fiable si vous essayez d'utiliser cette approche. Ce serait une excellente décision politique de la part de quelqu'un qui souhaite conserver SQL Server, mais ce n'est pas un bon moyen de migrer vers PostgreSQL.
Il existe un wrapper de données étrangères en lecture/écriture pour les nouvelles versions de Pg, mais il ne prendra initialement en charge que les autres serveurs PostgreSQL. La prise en charge de MS SQL serait beaucoup plus difficile en raison de la nécessité de traduire les sqlstates et les messages d'erreur, les conditions de recherche, etc., de sorte que tout wrapper serait sans aucun doute assez limité et aurait des performances moins que bonnes. Comme vous le dites, le support FDW est de toute façon trop immature à ce stade.
Il y a tellement de choses que vous perdez en essayant de faire un hybride comme celui-ci :
-
Aucune application de l'intégrité de la clé étrangère
-
Les types de données de chaque côté peuvent ne pas se comporter à 100 % de la même manière, de sorte que les données peuvent être correctes d'un côté et pas de l'autre. Pensez aux horodatages/dates.
-
Des jointures efficaces nécessiteraient un wrapper de données étrangères extrêmement sophistiqué - donc ce qui se passera généralement, c'est que toute la table sera récupérée puis jointe localement. Les performances seront terribles.
-
Écrire des requêtes devient un cauchemar lorsque vous faites autre chose que la tâche la plus triviale. Les noms de fonction diffèrent, etc.
-
Vous perdez ou affaiblissez de nombreuses propriétés ACID et/ou devez utiliser une validation en deux phases, ce qui est nul pour les performances.
Sérieusement, ne fais pas ça.
La synchronisation des bases de données est probablement encore pire - à moins que ce ne soit à sens unique, ce sera une recette pour les mises à jour perdues, les lignes supprimées réapparaissant et pire encore. La synchronisation bidirectionnelle est extrêmement dur.
Commencez à préparer vos applications pour un déménagement en les rendant capables de s'exécuter sur les deux serveurs, mais un seul à la fois. Une fois que l'application est prête à fonctionner sur Pg, commencez à effectuer des tests de charge et des tests de fiabilité avec une copie migrée des données en direct. alors pensez à migrer, mais ayez des plans pour inverser la tendance si vous rencontrez des problèmes de dernière minute qui vous obligent à retarder.
Si vous ajoutez des parties entièrement nouvelles à l'application, il peut être raisonnable de les avoir dans Pg si elles n'interagissent pas du tout avec les autres données de la base de données. C'est assez peu probable, cependant, et vos administrateurs système vous détesteront quand vous leur direz que vous avez maintenant besoin d'un instantané atomique sur deux bases de données distinctes...
