Tabele w różnych bazach danych

0

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.

1

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.

1

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ę).

1

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

1

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ć

2

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ł

1 użytkowników online, w tym zalogowanych: 0, gości: 1