Cześć, potrzebuje pomocy z logicznym rozplanowaniem kawałka bazy dla klubu fitness. Wg mnie zasada powinna być taka, że user kupuje karnet (fake zakup), do tabeli łączonej zapisuje się iduser oraz idkarnet i generuje klucz dostepu (chociaż nie wiem czy on jest w ogóle porzebny), po rezerwacji na dane zajęcia zmienia się ilość maksymalnych wejść użytkownikowi. Np kupił karnet na 12 wejść to po rezerwacji na jedne ma już tylko 11 itd.

Problem w tym, że nie bardzo wiem gdzie umieścić te ilość wejść i je modyfikowac przy każdej akcji. Kolumna pozostałe wejścia chyba nie jest dobrym pomysłem? podsunie ktoś jakiś pomysł ?
Chyba, że całkowicie źle się do tego zabrałem, to prosiłbym o oświecenie, chociaż termin mnie goni

baza
https://gyazo.com/bd7582bc24c7bc1b24ee4f4ce05344a1

Jeśli wszystkie karnety mają taki sam czas życia, nie potrzebujesz historii i kodów autoryzujących, to wcale nie jest potrzebna tabela z karnetami.
Można to umieścić w tabeli użytkowników i zmniejszać wartość przy każdym użyciu.

Jeśli będziesz wykorzystywał kody autoryzujące, a wszystkie karnety mają taki sam czas życia, to wtedy ilość pozostałych dni można przechowywać w kolumnie, która już tam jest, również zmniejszając przy każdym użyciu. Przy okazji masz historię karnetów (można zapisywać czas dodania, jak również ważność).

Jeśli karnety mają różny czas życia, to potrzebna jest jeszcze jedna tabela (typ karnetu) powiązana z karnetami. W niej przechowujesz czas życia, a ilość pozostałych dni już w kolumnie w tabeli karnetów.

Rozwiązanie zależy od wymagań.

Myślałem o pierwszym rozwiązaniu. Dodanie kolumny karnet do usera, przy zakupie wybranego dodaje mu odpowiednią liczbę a każda rezerwacja zmniejsza odpowiednio o 1. Tylko wtedy trzeba ifami sprawdzać jaki karnet zakupił użytkownik.

Czym jest czas życia? chodzi o termin wykorzystania? np 12 wejść na 60 dni ? Jeżeli tak, to nie przewidywałem w ogóle ograniczenia czasu- przynajmniej na razie.

Mógłbyś zobrazować drugi przykład?

"Czas życia" - tu miałem na myśli dostępną ilość. Może niezbyt udane określenie.

Drugi przykład jest zobrazowany na Twoim schemacie. Jeśli trzeba, można dodać pola: data dodania, data ważności.

To jeszcze podsumowując:

Przykład jaki podałem będzie ok, dostępna historia karnetów, może właśnie czas życia itd. Tylko jak dobrze rozumiem, to na klucz user musi być założony unique ponieważ, user w danym momencie może mieć tylko jeden karnet? dobrze rozumiem ?

Nie wiem co masz na myśli.


To raczej pytanie do Ciebie.

Chodzi o to, by user mógł mieć w danym momencie tylko jeden typ karnetu np na 12 wejść a nie, że będzie mógł kupić karnet na 12, 15 i 18 wejść. Z jednej strony można to zablokować przez właśnie unique na user_id w tabeli user-karnet a z drugiej w kodzie, sprawdzając czy już w tej tabeli jest taki user.

W kodzie i tak będzie sprawdzał czy ma karnet czy nie.
Natomiast jeśli chciałbyś założyć unique na id użytkownika, to musiałbyś zużyty karnet usuwać, aby dodać nowy.

Inna sprawa, to nie wiem czy przewidujesz możliwość dokupienia karnetu. Czyli jeśli klient ma aktywny karnet, dokupując nowy, przedłuża mu się ten pierwszy.

Tak, masz oczywiście rację, ale wtedy z historii zakupu nici i trzeba było by jeszcze dodatkową tabelę na historię wydaje mi się.

O przedłużeniu myślałem, ale chyba na razie pozostanę przy wersji 1 użytkownik=1 karnet i możliwość wykupienia dopiero po skończeniu aktywnego.

Usuwanie będzie wymuszone tym, że założysz unique na id użytkownika. I to miałem na myśli - nie to, że aby dodać nowy karnet trzeba usunąć stary, ale to, że tak będzie trzeba robić jeśli założysz unique.

No, i jeszcze inna sprawa, że zablokujesz sobie tym, to o czym piszesz, czyli historię zakupu karnetów (w tabeli karnet).
Odrębna tabela byłaby potrzebna gdybyś chciał przechowywać historię kolejnych użyć karnetu.

Teraz wszystko wyjaśnione i potwierdzone. Dzięki za pomoc