[Nofenak]

Mam tabelki: Halls (Sale), sale mają swoje miejsca (Seats), sale mają też seanse (Screenings), ale jednocześnie każdy seans ma własne miejsca ze statusem (wolne/zajęte), czyli mam jeszcze tabelkę ScreeningSeats. Czy takie rozwiązanie jest ok czy da się to lepiej zrobić?
#programowanie #naukaprogramowania #programista15k #java

[rolling_stone_with_no_hope]

@Nofenak: powiedz jeszcze że zrobiłeś to jako relację jpa … wrzuć jakiś diagram może pls

[Nofenak]

@rolling_stone_with_no_hope: Tak, używam JPA, diagram:

[Kekoludek]

@Nofenak: ktoś tu chyba ma zadanie rekrutacyjne do Touk... Zostajesz zgłoszony, że próbujesz oszukiwać.

[Nofenak]

@Kekoludek: Nie, to do mojej własnej apki

[pastarri]

@Nofenak: dobrze to ogarnąłeś, takie rozwiązanie które zaproponowałeś nazywa się junction table.

[MQs]

jednocześnie każdy seans ma własne miejsca ze statusem (wolne/zajęte)

@Nofenak: Pisałem ci już, że konkretny seans nie potrzebuje danych o wolnych miejscach, bo to są po prostu te, które nie zostały wykupione ze znanej listy dostępnych miejsc (sala). Może być jedynie potrzebne oddzielenie zajętych miejsc od kupionych biletów (kwestie finansowe), bo mogą dojść inne przyczyny, że miejsce nie jest dostępne (różnego typu rezerwacje/blokady). To że api/logika biznesowa będzie mogła odpowiedzieć na

[Nofenak]

@MQs: Ale muszę wyświetlić w API, które miejsa są wolne. Jak to zrobić w miarę prosto i wydajnie bez trzymania w bazie statusu miejsca? A no i dochodzi jeszcze problem lockingu. Chyba muszę też takie miejsce zablokować na poziomie bazy, żeby nikt 2 razy go nie zarezerwował.

[MQs]

@Nofenak: Miejsca zajęte będą w bazie - wolne są ustalane pośrednio (jeśli z miejsc {1,2,3,4,5} masz zajęte {2,3} to jakie są wolne? Czy 5 jest wolne czy zajęte?). Dlatego nie jest potrzebny status (tylko ewentualnie rodzaj blokady). Jak to zrobić to twój problem do rozwiązania - na tym polega nauka.