Aktywne Wpisy
Gours +489
Ostatni taniec na trumnie tego chłopaka 4 godziny przed ciszą wyborczą w wykonaniu Stanowskiego. Do tego stopnia posunęła się ta hiena, by pomóc KonfedePiSowi w niedzielnych wyborach. Ostry najazd na koalicję rządzącą - ten pajac ustawił się w roli wyroczni i mówi, że politycy i - jak twierdzi - „uśmiechnięta hałastra” mają krew na rękach.
Wyjątkowo obrzydliwe jest też układanie tez. Fakty są proste i trzeba być ostatnim debilem, żeby tego nie
Wyjątkowo obrzydliwe jest też układanie tez. Fakty są proste i trzeba być ostatnim debilem, żeby tego nie
wyscrollowany +447
#ukraina #rosja #konfederacja Pachoły Putina właśnie wysłały tę dziewczynę na ponad 5 lat do gulagu za krytykę inwazji na Ukrainę i powiedzenie prawdy o zbrodni w Buczy. Pięć lat za prawdę i kilka słów. Ale konfiarstwo i tak będzie klaskać uszami, bo JE Władymir to ich wymarzony konserwatywny car, a wolności słowa to nie ma w lewackiej Europie xdddddd
Czy jak w projekcie używacie mikroserwisów to czy każdy z nich ma osobną bazę danych? Słyszałem, że tak to powinno wyglądać, ale nie bardzo potrafię sobie wyobrazić w jaki sposób ma to działa jak mikroserwisy są w jakimś tam stopniu ze sobą powiązane. Na przykład:
1. Jeden serwis odpowiedzialny za płatności, a druga za zamówienia. Ale w zamówieniach mam relacje do płatności, więc w zamówieniach będę miał tabele ORDERTAB i kolumnie PAYMENTID bez klucza obcego? Bo mikroserwis payment jest odpowiedzialny za płatności więc w osobnej bazie danych mam tabele PAYMENTTAB.
2. Mam aplikację do generowania planu lekcji. Większość aplikacji opiera się na dodawaniu nauczycieli, sal itp. oraz na wyświetlaniu tego planu. Jednak generowanie planu lekcji jest bardzo zasobożerne, więc wydzielam z tego mikroserwis i odpowiednia to skaluje. To jak mam stworzyć osobną bazę danych do takiego mikroserwisu. I tu i tu muszę mieć tabele TEACHERTAB itp.
tl;dr Czy faktycznie stosuje się zawsze osobną bazę danych per mikroserwis? Rozumiem, że w serwisach które nie są ze sobą połączone domenowo jest to logiczne, ale co w takich przypadkach jak powyżej?
1. Tak, można użyć jakiegoś globalnego identyfikatora.
2. Tak, ale nie będą mieć takich samych danych, bo działają w innym kontekście. Przykładowo tabela 'Teacher' w serwisie do generowania planu lekcji będzie miała identyfikator i jakieś godziny dostępności, a w drugiej tabeli będzie ten sam identyfikator i jego dane personalne, kontaktowe itp.
Jak mikroserwisy współdzielą te same źródło danych, to masz do czynienia zwykle z big-ball-of-mud i ktoś źle wydzielił granice
@Patres: są różne podejścia i każde ma swoje wady i zalety. Decyzja o sposobie podzielenia storage (czy to bazy danych, czy storage blokowego czy nosql) nie
@Priya: Możesz to rozwinąć?
@jaca_66: bazy są problematyczne dlatego logikę najczęściej dzieli się pomiędzy serwis a bazę w taki sposób, żeby było najwygodniej. Jak chcesz, żeby baza była używana przez wiele serwisów to musisz dużą część logiki umieścić w bazie, żeby żaden serwis niczego nie popsuł. Pisanie logiki w bazie pod postacią triggerów i procedur jest bardzo upierdliwe (upierdliwy SQL, słaba testowalność, wersjonowanie, cachowanie) i większość ludzi, która spotkała się z czymś
- mają ukrytą zależność, którą jest baza danych. Rodzi to problemy w przypadku deploymentu: w idealnym rozwiązaniu serwisy powinny móc być deployowane niezależnie. Jeżeli współdzielą bazę i zmienię schemat, to musze w tym samym czasie podbić wersję w innym serwisie, żeby korzystał z nowego schematu.
- Wspólna baza danych może ograniczać skalowalność
- Jeżeli dwa serwisy współdzielą te same dane, tzn
Dzięki! Tylko w tym drugim