Witajcie,

zwykle nie miewam problemów z zaprojektowaniem bazy danych, ale napotkałem się na ciekawą sytuację przy bazie dla gry w Literki.

Gra jest wieloosobowa, jednocześnie może toczyć się wiele partii, a każdy gracz może grać w kilka partii jednocześnie. Wszystko pięknie, ale jak zaprojektować bazę dla logiki dobierania płytek?

Śpieszę wyjaśnić w czym jest problem. Moją pierwszą myślą było zrobić to tak (uwzględniam tylko istotne dla problemu tabele, a dla przyjaźniejszego odbioru przykładu nazywam tabele i pola po polsku):

1. `gry_gracze`
   
   • `id`
   • `gra_id`
   • `gracz_id`
   • `kolejnosc`
2. `ruchy`
   
   • `id`
   • `gra_gracz_id`
   • `czas`
3. `ruchy_płytki`
   
   • `id`
   • `ruch_id`
   • `płytka_id`
   • `indeks_pola`

Struktura wydaje się w porządku, ale nie pozwala na zapisanie płytek, które gracz losuje na samym początku gry. Pojawiają się tu cztery pomysły:

1. Przechowywać płytki startowe w osobnej tabeli z `id`, `gra_gracz_id` i `płytka_id`. Nie podoba mi się jednak ten pomysł, za duży bałagan.
2. Zamiast pola `ruch_id` w tabeli `ruchy_płytki` dać pole np. `referencja_id` i zmieniać jego znaczenie. Dla pierwszego ruchu byłoby to id `gra_gracz`, a dla kolejnych `ruch_id`. Ten pomysł już mi się w ogóle nie podoba, bo nie pozwala na założenie klucza obcego.
3. Przypisywać każdemu graczowi ruch już na początku, co nie byłoby aż takie głupie, bo w Literkach są i tak różne typy ruchów (gra, wymiana, pas), więc można by dodać typ dla tego celu. Nie jestem pewien jednak czy takie sztuczne dodawanie rekordów jest na miejscu, bo jednak te ruchy nie niosą za sobą żadnej informacji.
4. Pozwolić sobie na redundancję, czyli w tabeli `ruchy_płytki` dodać pole `gra_gracz_id`. Dla pierwszego ruchu pole `ruch_id` otrzymywałoby NULL, ale wciąż można by zlokalizować odpowiednią grę i gracza. To rozwiązanie też ma oczywiście dużą wadę, bo robimy masło maślane. Przecież dla kolejnych ruchów`gra_gracz_id` wynika już z `ruch_id`, więc nasza baza nie jest idealna

Mam nadzieję, że udało mi się obrazowo przedstawić problem. Co sądzicie o tych czterech pomysłach? Czy da się ten problem rozwiązać w ładniejszy sposób, pozbawiony wad?

Można powiedzieć, że losowanie tych 7 płytek czy ile ich tam jest, to też jest ruch gracza. Jak będziesz chciał robić statystyki może jakieś w przyszłości to przyda Ci się proste info, jakie losowano na początku płytki. Jak sam zauważyłeś trzeba też dodać typ, no chyba, że będziesz robił do tego osobną tabelę.
Więc zdecydowanie opcja nr 3 według mnie.

Z tych czterech ja też zdecydowanie skłaniam się ku opcji nr 3. Tak jak mówisz - chcę archiwizować te ruchy, dlatego nie wystarczy mi przechowywanie jedynie aktualnie posiadanych płytek

Dla mnie ranking tych pomysłów od najlepszego wygląda tak:

1. Pomysł trzeci
2. Pomysł czwarty
3. Pomysł pierwszy
4. Pomysł drugi

W sumie teraz do mnie dotarło, że to losowanie płytek na początku i tak też się odbywa zgodnie z kolejnością, więc to dodatkowy argument za opcją numer 3.

Dyskusja jednak trwa, może jest jakiś lepszy sposób