[php] sprawdzanie przedziałów czasowych Opcje

[grzegorz_g]

posiadam stronę coś w rodzaju rezerawcji pokoi.

Mam też formularz a w nim 2 pola

[HTML] pobierz, plaintext 
<input type="text" name="data_start" value="" />
<select name="okres" id="okres" >
<option value="1">1</option>
<option value="6">6</option>
<option value="12">12</option>
<option value="18">18</option>
<option value="24">24</option>
</select>
[HTML] pobierz, plaintext 

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

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

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
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ć

[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

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 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