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.