Wszystko, co proponujesz, to przepis na ból i nieudane migracje. Ludzie będą narzekać i zachwycać się tym, jak okropny, powolny i niewiarygodny jest PostgreSQL, jeśli spróbujesz użyć tego podejścia. Byłby to świetny ruch polityczny kogoś, kto chciałby zachować SQL Server, ale nie jest to dobry sposób na migrację do PostgreSQL.
W nowszych wersjach Pg pojawi się wrapper do odczytu/zapisu danych obcych, ale początkowo będzie on obsługiwał tylko inne serwery PostgreSQL. Obsługa MS SQL byłaby o wiele trudniejsza ze względu na konieczność tłumaczenia stanów sql i komunikatów o błędach, warunków wyszukiwania i nie tylko, więc każdy wrapper byłby bez wątpienia dość ograniczony i miałby mniej niż świetną wydajność. Jak mówisz, obsługa FDW i tak jest zbyt niedojrzała w tym momencie.
Jest tak wiele rzeczy, które tracisz, próbując zrobić hybrydę taką jak ta:
-
Brak wymuszania integralności klucza obcego
-
Typy danych po każdej stronie mogą nie zachowywać się w 100% tak samo, więc dane mogą być prawidłowe po jednej stronie, a po drugiej nie. Pomyśl o znacznikach czasu/datach.
-
Wydajne sprzężenia wymagałyby niezwykle wyrafinowanego opakowania danych obcych - więc zwykle zdarza się, że cała tabela zostanie pobrana, a następnie złączona lokalnie. Wydajność będzie okropna.
-
Pisanie zapytań staje się koszmarem, gdy robisz cokolwiek poza najbardziej trywialnym zadaniem. Nazwy funkcji różnią się itp.
-
Tracisz lub osłabiasz wiele właściwości ACID i/lub musisz użyć zatwierdzania dwufazowego, co jest do bani dla wydajności.
Poważnie, nie rób tego.
Synchronizacja baz danych jest prawdopodobnie jeszcze gorsza – chyba że jest to jeden sposób, będzie to recepta na utracone aktualizacje, ponowne pojawienie się usuniętych wierszy i jeszcze gorzej. Synchronizacja dwukierunkowa jest niezwykle trudne.
Zacznij przygotowywać swoje aplikacje do przeprowadzki, umożliwiając ich działanie na obu serwerach, ale tylko na jednym na raz. Po przygotowaniu aplikacji do uruchomienia na Pg zacznij przeprowadzać testy obciążenia i testy niezawodności za pomocą zmigrowanej kopii danych na żywo. wtedy pomyśl o migracji, ale zaplanuj, jak odwrócić ten ruch, jeśli znajdziesz w ostatniej chwili problemy, które zmuszają Cię do opóźnienia.
Jeśli dodajesz całkowicie nowe części do aplikacji, rozsądne może być umieszczenie ich w Pg, jeśli w ogóle nie wchodzą w interakcję z innymi danymi w bazie danych. Jest to jednak dość mało prawdopodobne, a administratorzy nadal będą Cię nienawidzić, gdy powiesz im, że potrzebujesz teraz atomowej migawki w dwóch oddzielnych bazach danych...
