Pomoc - Szukaj - Użytkownicy - Kalendarz
Pełna wersja: [php] sprawdzanie przedziałów czasowych
Forum PHP.pl > Forum > PHP
grzegorz_g
posiadam stronę coś w rodzaju rezerawcji pokoi.

Mam też formularz a w nim 2 pola
  1. <input type="text" name="data_start" value="" />
  2. <select name="okres" id="okres" >
  3. <option value="1">1</option>
  4. <option value="6">6</option>
  5. <option value="12">12</option>
  6. <option value="18">18</option>
  7. <option value="24">24</option>


teraz jednak potrzebuje po wysłaniu formularza (a jaby się dało sprawdzić to nawet przed) czy pokój w tym czasie jest wolny

do bazy zapisuje datę w formie mktime

  1. <?php
  2. $datka=explode("-",$_POST['data_start']);
  3. $data_start=mktime(0,0,0,$datka[1],$datka[0],$datka[2]);
  4. $data_end=$data_start+(60*60*24*$okres);
  5. ?>


no i teraz jest problem jak sprawdzić czy ten okres wybrany przez usera nie jest już w bazie?

CZekam na sugestie, za które wielkie dzięki
scanner
Musisz policzyć wszystkie rezerwacje na dany pokój, dla których podany początek rezerwacji lub wyliczony koniec znajduje się BETWEEN (wskazówka) początku ich (istniejących już) rezerwacji.
Przy okazji - podawanie długości rezerwacji jest średnio wygodne - user wie, od kiedy do kiedy chce rezerwować - to primo. Jako sekundo dopiero na ile dni.

Polecałbym zatem zarówno po stronie usera (JS) jak i kodu (jakby JS był wyłączony) obliczanie daty końcowej i tez trzymanie jej w bazie.
Wierz mi - kilka systemów rezerwacyjnych/urlopowych zrobiliśmy w mentaxie - właśnie jeden z nich kończę.
Cysiaczek
@scanner, a to chętnie się dowiem, jaką strukturę bazy obraliście smile.gif
Właśnie doszlifowuje mój system rezerwacji i rozwiązałem to trochę nietypowo.
Przechowuję w bazie jedynie rekordy odpowiadająca dniom zarezerwowanym. Każdy dzień jest przechowywany maksymalnie w dwóch rekordach (AM/PM lub AMPM , bo system zakłada podział dnia na rano i wieczór). Całość sprowadza się do maksymalnie dwóch zapytań, jeśli chodzi o możliwość rezerwacji. Jedynie wyszukiwanie wolnych terminów jest nieco utrudnione, co dziś mi ~mike pomógł uświadomić sad.gif
scanner
Akurat jeśli chodzi o strukture bazy, to z jest to dośc duży temat, całośc oparta zawsze jest bowiem o mentaxowy MyCRM, który dosc dużo potrafi smile.gif

Ale sam temat rezerwacji, to dośc trywialna sprawa

Tablica rezerwacje:
  • ID_zasosu
  • Data_poczatku
  • Data_konca
  • ew. status rezerwacji
  • ... inne dane

Podczas rezerwowania zasobu, musimy sprawdzić:
  1. Dla podanego zasobu:
  2. Czy początek daty proponowanej znajduje się w zakresie jakiejkolwiek istniejącej rezerwacji
  3. Czy koniec daty proponowanej znajduje się w zakresie jakiejkolwiek istniejącej rezerwacji
  4. Czy jakakolwiek istniejąca rezerwacja zaczyna się w proponowanym zakresie
  5. Czy jakakolwiek istniejąca rezerwacja kończy się w proponowanym zakresie
  6. Czy jakakolwiek rezerwacja zaczyna się przed podanym zakresem a kończy po nim
Całość jest do sprawdzenia jednym zapytaniem.
Cysiaczek
Pewnie i jest to wystarczające.
Wchodząc w szczegóły:
Założyłem, że więcej jest odczytów z tabeli niż operacji zapisu do niej.
Tabela rezerwacji przechowuje daty początku i końca, ale istnieją dwie dodatkowe tabele.
Kod
  bookings_calendar:
    _attributes:  { phpName: BookingEntry }
    id:
    apartment_id: { type: integer, required: true, foreignTable: apartments, foreignReference: id }
    order_id:     { type: integer, required: true, foreignTable: orders, foreignReference: id }
    date:         { type: date, required: true }
    state:        { type: tinyint, required: true, default: 1 }
    type:         { type: tinyint, required: true, default: 0 }
    events:       { type: integer, default: NULL, foreignTable: bookings_events, foreignReference: id }
    skip:         { type: boolean, default: false }
    
  temp_bookings_calendar:
    _attributes:  { phpName: TempBookingEntry }
    id:
    apartment_id: { type: integer, required: true, foreignTable: apartments, foreignReference: id }
    date:         { type: date, required: true }
    state:        { type: tinyint, required: true, default: 1 }
    session_id:  { type: varchar, size: 128, required: true }
    expire_date:  { type: timestamp }


Służą one do sprawdzania dostępności i do rysowania kalendarza. Tabela temp_booking_calendar przechwuje tylko wstępne rezerwacje - klient zaznacza zakres dat, wypełnia formularz i otrzymuje stronę z prośbą o potwierdzenie. Jeśli potwierdzi (kliknie "tak, jestem pewien") dane sa przenoszone do tabeli bookings_calendar i oznaczane jako "oczekujące" - zazwyczaj chodzi o potwierdzenie wpłaty.

W zasadzie wyrysowanie kalendarza to pestka, bo powiedzmy, dla jednego miesiąca wyciągamy maksymalnie 62 rekordy i trzeba na nich tylko raz dokonać jakiejś obróbki, żeby było wiadomo, jaki obrazek podstawić w komórce tabeli.

Wada to jak wspomniałem, wyszukiwanie wolnych terminów - nie ma ich w bazie, więc trzeba wyciągnąć wszystkie rekordy z żądanego zakresu, utworzyć dodatkową tablicę ze wszystkimi datami i dopiero wtedy, w pętli zdejmować z niej te dni, które wyciągnęliśmy z bazy. To, co w niej zostanie, to dni wolne smile.gif Nie jest to zbyt wydajne, więc chyba spróbuję wykorzystać dane z tabeli zamówień, zgodnie z tym, cp napisałeś
Mało wydajne jest też wstawianie rekordów - w Propelu to masakra - nie polecam :/

Z samego efektu jestem jednak zadowolony.
http://img56.imageshack.us/img56/8348/cal3nt4.png (dodatkowo uzupełniłem o eventy)

Pozdrawiam
To jest wersja lo-fi głównej zawartości. Aby zobaczyć pełną wersję z większą zawartością, obrazkami i formatowaniem proszę kliknij tutaj.
Invision Power Board © 2001-2025 Invision Power Services, Inc.