Widać że nie odsłuchałeś całości. W innych filmach używam Dockera np do uruchomienia PostgreSQL i bez wiedzy na temat Dockera widz nie zrozumie co tam się dzieje. Docker nie jest niezbędny, ale jeśli widz go nie zna to odsyłam go do tego filmu aby poznał podstawy i rozumiał co dzieje się w innych filmach.

Ze względu że jest to materiał od podstaw to jest skrót myślowy, ale patrząc głębiej to tak masz racje. Chodzi mi o to że otrzymujemy w kontenerze pełno prawny system operacyjny niezależny od drugiego kontenera, a dodatkowo każdy kontener może mieć inną wersje systemu.

czy moze Intellij?

@@slavicdesign1837 Hej to jest Visual Studio Code, kiedyś pisałem w Intellij ale przesiadłem się jakieś2 lata temu. Co do drugiego pytania to tak to jest PgAdmin :)

Hej, usunięte ID-ki już się nie używa ponownie. Dzięki temu unikniesz problemów pojawienia się innych danych pod tym samym ID. Rozważmy prosty przykład z blogiem: Wyobraź sobie że masz artykuł o tytule "ABC" z ID 2, wyświetla się on pod adresem <jakas-domena-bloga.pl>/post/2. Usuwasz go i wskakuje w to miejsce nowy artykuł "DEF" o tym samym ID. Osoby które miały zapamiętane (jak i również Google indeksował) link do artykuły "ABC" teraz widzą "DEF". Powoduje to pewną niezgodę. Ten przykład jest akurat bardzo błachy, ale może być więcej takich problemy np: z CACHE w aplikacji, niepoprawnym sczyszczeniem danych po poprzednim wpisie. Cieżko jest to potem naprawić bo nie wiesz które dane są stare, a które nowe. Tak masz pewność że nowy dane mają swój unikalny ID. W PostgreSQL zakres SERIAL jest dużo od 1 do 2147483647. Jeśli to za mało to możesz zdefiniować ID jako BIGSERIAL wtedy zakres będzie: od 1 do 9223372036854775807. P.S. jeśli powyższy przykład nie jest przekonujący, to wyobraź sobie że PESEL przechodzi na nowo urodzone dziecko po zmarłej osobie. Jeśli zmarła osoba miała długi (np. kredyt), to nowo narodzone dziecko ma już kredyt zanim poznała co to są pieniądze. Dlatego unikamy dziedziczenia unikalnego ID na nowe wpisy.

Z tego co kojarzę to FC nie polecano właśnie na prop children. Był domyślnie dodany mimo, że nie zawsze się go wykorzystywało. Teraz jak widać się to zmieniło. Rozwiń temat, jak masz więcej informacji dlatego FC się nie poleca to chętnie przeczytam i inni napewno też.

Hejka, dzięki za ten przykład, jest naprawdę rozbudowany i można na nim znaleść kilka rozwiązań w zależności od skomplikowania systemu pod hotel. Co do twojego przykładu rozważ propozycję którą rozpisałem tutaj: miro.com/app/board/uXjVPID2mdc=/?share_link_id=948629317359 (jak problemy z linkiem to daj znać). Jest tam dodatkowa tabela "pobyt" która ma jednego klienta, a klient może mieć wiele pobytów (wiele do jeden). Pobyt może mieć kolumnę "type" z wartościami (all inclusive, standard, itp...) do tego może mieć od 0 do wielu zamówień (relacje jeden do wiele) i jeśli jest all inclusive zamówienie miał by odrazu status opłacony. Relacja pobyt (lub jeśli nie dasz tej tabeli to tabela klient) do pokój to wiele do wiele z walidacją po stronie aplikacji, że ten sam pokój nie może mieć dwóch pobytów w tym samym czasie. Co do pytania o relacje jeden do jeden gdzie jej szukać. Tutaj jest dość duża dowolność i można kilka znaleść lub nie dawać jej w ogóle. Możesz np. wydzielić dane do faktury do osobnej tabeli, aby nie było zbyt dużo kolumn w tabeli klient (to relacja jeden do jeden z oznaczeniem 1..0 bo nie każdy potrzebuje faktury, tylko może wziąć paragon). Do każdego przypadku można podejść na kilka sposobów i nie znaczy że któryś jest zły.

@@lubie-programowac Dziękuję za obszerną odpowiedź. Można też zacząć jak na filmie od tabel: order, product np. drinki, customer, address np. numer pokoju, bar miejsce wykonania zamówienia oraz employee barman. Męczę się nad pomysłem na jakieś web api.