Aktywne Wpisy
WielkiNos +415
Jak szłam kiedyś w maju nad Morskie Oko, na szlaku leżał jeszcze śnieg a w oczy wiał silny wiatr myślałam tylko o tym ile jeszcze i że mi zimno w nos. Byłam przekonana, że faceci mają podobnie. Okazuje się, że nie bo według lewactwa jedyne o czym myślą faceci na zaśnieżonym szlaku to zabawić się z przechodzącą akurat obok babą.
#lewackalogika #bekazlewactwa #wysokieobcasy #gory
#lewackalogika #bekazlewactwa #wysokieobcasy #gory
źródło: temp_file5142674393861254714
Pobierz
Silimarillo +15
Ja #!$%@? nie ogarniam. Typiara poznana na #tinder, dwa spotkania zajebista gadka czuć że też się stara. No czuć chemię, są małe motylki w brzuchu. Sama proponuje kolejne spotkanie, sama wymyśla co będziemy robić w tym okresie podczas pisania leci fajny flircik. W dniu spotkania jeb ja cię przepraszam babcia chora nie dam rady. No #!$%@?, spoko wypadają różne sytuacje xd I #!$%@? od tamtej pory udaje że nie istnieje xdxd
Aktywne Znaleziska
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