Robię system rezerwacji w PHP, gdzie będzie kilku użytkowników. Dla każdego użytkownika dostępne będą inne dni tygodnia, które będzie można zmieniać w panelu administratora, co wymusza zastosowanie bazy danych. Jak stworzyć tabelę w tej bazie. Na tę chwilę przychodzi mi na myśl poniższa tabela:
Następnie z tej tabeli pobierać wartości dla wszystkich dni tygodnia dla wybranego użytkownika i w pętli dla wszystkich dni sprawdzać wartość. W przypadku "true" udostępniać te dni tygodnia w kalendarzu. Czy można jakoś lepiej podejść do tego zagadnienia?
0
0
Bednarus3 napisał(a):
Robię system rezerwacji w PHP, gdzie będzie kilku użytkowników. Dla każdego użytkownika dostępne będą inne dni tygodnia, które będzie można zmieniać w panelu administratora, co wymusza zastosowanie bazy danych.
W sumie to nie. To wymusza tylko zapisanie gdzieś danych, ale nie koniecznie w bazie.
Bednarus3 napisał(a):
Jak stworzyć tabelę w tej bazie. Na tę chwilę przychodzi mi na myśl poniższa tabela:
Następnie z tej tabeli pobierać wartości dla wszystkich dni tygodnia dla wybranego użytkownika i w pętli dla wszystkich dni sprawdzać wartość. W przypadku "true" udostępniać te dni tygodnia w kalendarzu. Czy można jakoś lepiej podejść do tego zagadnienia?
Nie potrzebnie myślisz o logice swojej aplikacji przez pryzmat persystencji.
0
Dla jednego użytkownika mogą wystąpić różne wzorce dniowe. Np okres zwykly, świąteczny, wakacyjny, zimowy itd. Do tego możesz mieć wyjątki w stosunku do standardowego wzorca dniowego.
Jeżeli mamy w tyłku godziny to można to np zapisać tak:
ServiceDay(użytkownik, start, koniec, pon, wto,sro,czw,pio,sob,nie)
ServiceDayException(uzytkownik, dzien, typ wyjatku(dodany/usuniety))
0
Bednarus3 napisał(a):
Czy można jakoś lepiej podejść do tego zagadnienia?
Może nie prościej ale poprawniej na 100%.
Tworzysz tabele:
+-------------------
| user
+-------------------
| idUser (int primary key)
| name (string)
| ...
+-------------------
+-------------------
| userDayOfWeek
+-------------------
| idUserDayOfWeek (int primary key)
| idUser (int)
| dayOfWeek (int lub enum('su', 'mo', 'tu', 'we', 'th', 'fr', 'sa' ) )
| ...
+-------------------
Teraz jak chcesz zobaczyć jakie dany użytkownik ma dostępne dni tygodnia to wywołujesz SQL:
SELECT dayOfWeek from userDayOfWeek where idUser=[idUser]
0
Dziękuję.
Rozumiem, że każdy dzień będzie przechowywany w osobnym rekordzie. Jeżeli użytkownik, dla którego idUser=0 będzie miał dostęp do wszystkich dni tygodnia, to w bazie będzie 7 rekordów, gdzie w każdym będzie odpowiednia liczba odpowiadająca dniowi tygodnia.
W międzyczasie przyszło mi do głowy rozwiązanie rodem z programowania mikrokontrolerów. Struktura bazy danych się nie zmienia. Tylko zamiast siedmiu rekordów zawsze będzie będzie jeden. Teraz, dla wszystkich dni tygodnia, będzie zawierał liczbę 127 (0b1111111). Dla dostępnej tylko środy będzie to liczba 8 (0b1000). Natomiast po stronie skryptu, w moim przypadku PHP, będą operacje bitowe dla sprawdzenia który dzień tygodnia jest dostępny:
$daysOfWeek = xxx; //xxx oznacza wartość pobraną z bazy danych przypisaną wybranemu użytkownikowi.
for ($i=0; $i<7; $i++)
{
if ($daysOfWeek & 1<<$i)
{
echo "true";
}
else
{
echo "false";
}
}
Takie rozwiązanie łatwo zmienić aby klient sprawdzał dostępne dni. W moim przypadku, gdzie ilość jednoczesnych zapytań do serwera PHP i serwera bazy danych będzie znikoma nie ma to znaczenia. Jeżeli obciążenie serwera byłoby duże, to zapytanie do bazy danych będzie szybciej zrealizowane. PHP tylko zwróci wartość klientowi i maszyna klienta zrobi resztę roboty. Jak oceniacie takie rozwiązanie?
0
Bednarus3 napisał(a):
W międzyczasie przyszło mi do głowy rozwiązanie rodem z programowania mikrokontrolerów. Struktura bazy danych się nie zmienia. Tylko zamiast siedmiu rekordów zawsze będzie będzie jeden. Teraz, dla wszystkich dni tygodnia, będzie zawierał liczbę 127 (0b1111111). Dla dostępnej tylko środy będzie to liczba 8 (0b1000).
Jasne, że można ale jak sam napisałeś to rozwiązanie z uC. W elektronice taki sposób programowania to zupełnie normalna rzecz, ale przy tworzeniu stron to już grube przegięcie pały :-)
Jeśli masz mało danych to można je nawet trzymać w tablicy i stan zapisywać do pliku jako JSON, zrezygnując z SQL.
Pozostają pytania:
- Jak rozwojowy jest projekt?
- Czy ma być napisane zgodnie ze sztuką?
- Jakie są pozostałe założenia projektu?