Всичко, което предлагате, е рецепта за болка и неуспешни миграции. Хората ще бълнуват и ще се възмущават колко ужасен, бавен и ненадежден е PostgreSQL, ако се опитате да използвате този подход. Би било страхотен политически ход от някой, който иска да запази SQL Server, но не и добър начин за мигриране към PostgreSQL.
Има обвивка на чужди данни за четене/запис, идваща за по-новите версии на Pg, но първоначално ще поддържа само други сървъри на PostgreSQL. Поддържането на MS SQL би било много по-трудно поради необходимостта от превод на sqlstates и съобщения за грешка, условия за търсене и други, така че всяка обвивка без съмнение би била доста ограничена и нямаше толкова голяма производителност. Както казвате, поддръжката на FDW е твърде незряла на този етап.
Има толкова много неща, които губите, опитвайки се да направите хибрид като този:
-
Без прилагане на целостта на външния ключ
-
Типовете данни от всяка страна може да не се държат 100% еднакво, така че данните може да са ОК от едната страна, а не от другата. Помислете за клеймото за време/датите.
-
Ефективните присъединявания ще изискват изключително сложна чужда обвивка на данни - така че това, което обикновено се случва, е, че цялата таблица ще бъде извлечена и след това ще се съедини срещу локално. Изпълнението ще бъде ужасно.
-
Писането на заявки се превръща в кошмар, когато правите всичко друго, но не и най-тривиалната задача. Имената на функциите се различават и т.н.
-
Вие губите или отслабвате много свойства на ACID и/или трябва да използвате двуфазов комит, което е лошо за производителността.
Сериозно, не правете това.
Синхронизирането на DB вероятно е още по-лошо - освен ако не е еднопосочно, това ще бъде рецепта за загубени актуализации, повторно появяване на изтрити редове и още по-лошо. Двупосочната синхронизация е изключително трудно.
Започнете да подготвяте приложенията си за преместване, като ги накарате да работят и на двата сървъра, но само един по един. След като сте подготвили приложението да работи на Pg, започнете да правите някои тестове за натоварване и тестове за надеждност с мигрирано копие на живите данни. тогава помислете за мигриране, но имайте планове как да отмените преместването, ако откриете проблеми в последния момент, които ви принуждават да отлагате.
Ако добавяте изцяло нови части към приложението, може да е разумно да ги имате в Pg, ако изобщо не взаимодействат с другите данни в DB. Това обаче е доста малко вероятно и вашите системни администратори все още ще ви мразят, когато им кажете, че сега имате нужда от атомарна моментна снимка в две отделни бази данни...
