I am building a mobile webapp with jquery mobile. Now let me first sketch the thing I am doing.
A user want to reserve a meeting-room. First he chooses a room and only that room he wants to reserve, no other one. Than he also enters a begin and end DATETIME. This is the period he wants to have this room.
Now, I have a function in my webservice which gives a list back with all the reservations that are made on that specific meeting-room. Later on I am going to check in my javascript if this list is empty or not.
Now my Database structure.
I have table Reservations with the following design
ID --> int
ROOMID --> int
DATE_BEGIN --> DATETIME
DATE_END --> DATETIME
I have also a table ROOM with the following design
ID --> int
NAME --> VARCHAR(30)
Now an insert of a row in the table reservation looks like this
ID --> 1
ROOMID --> 2
DATE_BEGIN --> 2012-01-01 12:02:33
DATE_END --> 2012-01-01 14:00:00
For now I have this query
SELECT res.DATE_BEGIN,res.DATE_END
FROM reservations res
INNER JOIN room roo
ON res.ROOMID =roo.ID
WHERE WHERE res.DATE_BEGIN <> @DATE_BEGIN
AND res_DATE_END <> @DATE_END
Now my question is what query should it be to get the right result. Also the reservations that are in the past shoud be filtered out.
Could anybody help ?
Thank you
You need to check if one date range overlaps another date range.
Only Test1 and Test5 do not overlap.
Colisions can therefore be found with…
Note:
Take care with boundary conditions. If one meeting ends and 10am and another starts at 10am, this wouldn’t normally be considered an overlap. Which is why I use
<and>.EDIT
For reasons out of the scope of this question and answer, such a query as I highlighted above is not easily optimised using indexes.
For this reason, an alternative approach is to create blocks of time for which the room can be booked. No-one needs to start a meeting at 2 minutes and 33 seconds past mid-day. Instead they’d start it at 12:00. As such blocks of 5 minutes are normally accurate enough, and indeed systems often use 15 minute blocks or even 30 minute blocks.
This means one booking can take multiple records (1 record per block of time booked), but every query on that data become simpler to resolve.