Tabele w różnych bazach danych

Czy ma ktoś jakieś sensowne materiały / artykuły podejmujące problem podziału na kilka baz danych SQL? Udało mi się znaleźć jedynie jakieś wyrwane z kontekstu pytania na stacku. Nie mówię tu o backupowaniu danych, ale o wydzieleniu tabel i wrzuceniu ich do różnych baz. Chodzi mi o korzyści / wady, kiedy to się robi, kiedy nie powinno, co z relacjami, foreign keysami, jak to się ma do pozostałej architektury systemu (np. podziału na mniejsze serwisy), itd. Czy jest jakaś zasada, jakaś prosta odpowiedź, czy decyzja o takim podziale wymaga głębszej analizy, przygotowaina najpierw komplentego schematu tabel z relacjami?
Nie chcę podawać dla jakiego konkretnego problemu potrzebuję odpowiedzi, chciałbym na razie bardziej zorientować się w tematyce.

Ja widzę jedno rozsądne rozwiązanie. Dwie bazy: jedna baza dla aplikacji (jej ustawień, modułów, ew. loginów i dostępów), druga baza stricte dla danych klienta. Wtedy, gdy klient zażyczy sobie backup danych, to dostanie TYLKO swoje dane.

dzielenie logicznie spójnych danych na wiele baz jest wg mnie złe. Są inne rozwiązania jeśli problemem jest wydajność (innego możliwego problemu do rozwiązania w ten sposób nie widzę).

Czyżby po modzie na mikroserwisy i mikrofrontend nadeszła moda na mikro bazy?
Chyba nie, bo podział monolitycznej bazy był już robiony przy okazji mikroserwisów więc strzelam że materiały o mikroserwisach mogą być przydatne tutaj też. Zwłaszcza koncepcja kontekstu ograniczonego.

Czy widzę jakieś zalety mikrobaz danych pracujących z monolitem czyli pojedynczą aplikacją?
Chyba tylko wydajność lub ilość danych. Np podobno PostgreSQL działa dobrze tylko do 1T na jednej instancji

Przy dużych systemach masz rozdział całości na kilka baz i serwerów

potem wszystko się spina szyną integracyjną

w starszych czasach np część do systemu sprzedażowego wymagane dane miała synchronizowane z głównego systemu, dzięki temu przy jakiejś wywałce innego serwera to sobie nadal działało osobno i można towar sprzedawać

Kolejny wątek, że OP nas opuścił ...

"w przyszłości może będzie integrowany" -> bazy zupełnie oddzielne, tzn nie projektowane do wymienialności baza-baza, tylko apliakcja-apliakcja.
EDIT: oczywiście baza każdej aplikacji kompletna, spójna, tzn w żadnej mierze nie "kaleka".

Marcin.Miga napisał(a):

Ja widzę jedno rozsądne rozwiązanie. Dwie bazy: jedna baza dla aplikacji (jej ustawień, modułów, ew. loginów i dostępów), druga baza stricte dla danych klienta. Wtedy, gdy klient zażyczy sobie backup danych, to dostanie TYLKO swoje dane.

To jest ważny pomysł