In questo articolo trovate alcuni consigli per lo sviluppo di un sistema di gestione prenotazioni (i cosiddetti "booking engine"), utili sia per evitare il famigerato overbooking, sia per consentire al vostri sistema di crescere con il tempo.
Primo problema per chi si trova ad affrontare un sistema di gestione prenotazioni, sia che si tratti dell'affitto di case vacanze, sia che si tratti di visite mediche o lezioni private, è l'impostazione della base dati. Quello che vi consiglio è di utilizzare una tabella molto semplice in cui memorizzare le prenotazioni.
E' sufficiente una tabella 'prenotazioni' con i classici campi:
- un id autoincrement prenotazioni_id
- l'id della struttura (id della casa vacanze, della stanza dell'albergo..), un generico item_id
- la data di inizio prenotazione, prenotazioni_da
- la data di fine prenotazione, prenotazioni_a
- uno status, il classico flag 0/1 per tener traccia di prenotazioni eliminate (prenotazioni_status)
A questo punto la query che verifica la disponibilità, prima che un utente provi ad inoltrare una richiesta di prenotazione è di questo tipo (utilizzo volutamente l'obsoleta funzione mysql_query() per focalizzare la vostra attenzione soltanto sulla logica, poi ovviamente utilizzerete la libreria database che riterrete opportuna)
function verifica_disponibilita($id_struttura, $book_from, $book_to){
$verifica = mysql_query('select count(*) as totale from prenotazioni p where p.item_id='.$id_struttura.' and (("'.$book_from .'" <= p.prenotazioni_da and "'.$book_to.'" >= p.prenotazioni_a) or ("'.$book_from .'" >= p.prenotazioni_da and "'.$book_to.'" <= p.prenotazioni_a) or ("'.$book_to.'" between p.prenotazioni_da and p.prenotazioni_a) or ("'.$book_from .'" between p.prenotazioni_da and p.prenotazioni_a) )') or die(mysql_error());
return mysql_result($verifica, 0, 0);
}
Questa query riceve come parametro l'id della struttura, la data di inizio soggiorno (ad esempio 28 marzo, "2020-03-28"), la data di fine (3 aprile = "2020-04-03").
Viene quindi verificato che nel database non ci siano record:
- compresi tra queste due date (ad esempio un soggiorno che inizia il 29 marzo e finisce il 1 aprile)
- che inizino prima delle nostre date ma finiscano durante (26-29 marzo)
- che finiscano dopo le nostre date ma che inizino durante (2-6 aprile)
Attenzione a passare come $book_to la data di fine alloggio. Nelle prenotazioni alberghiere gli utenti ragionano in termini di checkin/checkout, per cui vorranno prenotare "da 28 marzo al 4 aprile" intendendo di arrivare nel vostro albergo il 28 marzo, ma di voler andar via la mattina del 4 aprile. Per cui, per voi, il 4 aprile è una data libera (altri utenti potranno occupare quella stanza, nel pomeriggio) e quindi nel database vi conviene ragionare, riguardo la data di fine soggiorno, come data di "ultima notte" e non di "partenza".
Un altro consiglio: come vedete ho messo una tabella di prenotazioni molto leggera. Tutti gli altri dati, a partire da quelli anagrafici, li memorizzo di solito in un'altra tabella ("ordini"), con un campo "prenotazioni_id" che mi permette di mettere in relazione questi dati. Questo perchè se in futuro volessimo integrare un calendario esterno (prenotazioni in arrivo da booking.com oppure da channel manager come Avantio o Kigo), non sapendo quanti dati ci metteranno a disposizione (alcuni passano solo le date di checkin/checkout e un codice), non avremmo modo di compilare i dati anagrafici. Per cui preferisco tenere una tabella "ordini" che poi farò gestire al cliente attraverso il proprio pannello di amministrazione sul mio sito, ed una tabella "prenotazioni" in cui finiscono sia gli ordini del nostro booking engine, sia quelli di siti di terze parti.