Tutto ciò che suggerisci è una ricetta per il dolore e le migrazioni fallite. Le persone inveireranno e si rallegreranno di quanto sia orribile, lento e inaffidabile PostgreSQL se si tenta di utilizzare questo approccio. Sarebbe un'ottima mossa politica da parte di qualcuno che volesse mantenere SQL Server, ma non un buon modo per migrare a PostgreSQL.
C'è un wrapper di dati esterni di lettura/scrittura in arrivo per le versioni Pg più recenti, ma inizialmente supporterà solo altri server PostgreSQL. Il supporto di MS SQL sarebbe molto più difficile a causa della necessità di tradurre sqlstates e messaggi di errore, condizioni di ricerca e altro, quindi qualsiasi wrapper sarebbe senza dubbio piuttosto limitato e avrebbe prestazioni non eccezionali. Come dici tu, il supporto FDW è comunque troppo immaturo a questo punto.
Ci sono così tante cose che perdi cercando di fare un ibrido come questo:
-
Nessuna applicazione dell'integrità della chiave esterna
-
I tipi di dati su ciascun lato potrebbero non comportarsi allo stesso modo al 100%, quindi i dati potrebbero essere OK su un lato e non sull'altro. Pensa a timestamp/date.
-
Join efficienti richiederebbero un wrapper di dati esterno estremamente sofisticato, quindi ciò che di solito accade è che l'intera tabella verrà recuperata e quindi unita a livello locale. Le prestazioni saranno terribili.
-
Scrivere query diventa un incubo quando stai facendo qualsiasi cosa tranne il compito più banale. I nomi delle funzioni differiscono, ecc.
-
Perdi o indebolisci molte proprietà ACID e/o devi utilizzare il commit a due fasi, il che fa schifo per le prestazioni.
Seriamente, non farlo.
La sincronizzazione dei DB è probabilmente anche peggio:a meno che non sia un modo, sarà una ricetta per aggiornamenti persi, righe eliminate che riappaiono e peggio. La sincronizzazione bidirezionale è estremamente difficile.
Inizia a preparare le tue app per il trasloco rendendole in grado di funzionare su entrambi i server, ma solo uno alla volta. Una volta che l'app è pronta per l'esecuzione su Pg, inizia a eseguire alcuni test di carico e di affidabilità con una copia migrata dei dati in tempo reale. allora pensa alla migrazione, ma pianifica come invertire la mossa se trovi problemi dell'ultimo minuto che ti costringono a ritardare.
Se stai aggiungendo parti completamente nuove all'app, potrebbe essere ragionevole averle in Pg se non interagiscono affatto con gli altri dati nel DB. È piuttosto improbabile, tuttavia, e i tuoi amministratori di sistema ti odieranno ancora quando dirai loro che ora hai bisogno di uno snapshot atomico su due database separati...
