You’re plan would entail a table with arbitrarily many rows (representing the various rooms, if there are lots and lots of them) and arbitrarily many columns (one for each date, and I suppose you would keep adding new columns as you open the reservation books for each new month or whatever). A general rule for DB design is that you should have a fairly fixed number of columns and not just keep adding columns like that. It would also be difficult to search a database designed like that, at least with typical modern relational DB design.
(1) Have one table that lists every existing room (or other schedulable resources maybe). The first column is an ID number (the primary key) that identifies that room. Other fields can have additional information describing the room, like what building it is in, what floor, the floor size, how many people it can accommodate, or whatever. Each room is a separate ROW in the table. You can add or delete rows as needed.
(2) Have another table listing every DATE that the facilities are potentially available. You might be able to get by without this table, since in concept its rows (simply a list of days) could be generated on the fly anyway.
(3) Have a third table - and this is the important one - listing what rooms are available on what days. This has one column containing the ID linking to the room in question, and one column with the ID linking to the date in question (or, if you don’t have a date table, it would be just the date). Additional fields might contain the reservation information. (We’re keeping it simple – assuming just one reservation per room per day. If a room is reserved in hour-blocks and can have several reservations each day, that’s messier.)
The two columns (room ID linking to the room table, and date ID linking to the date table or simply the date itself) together form the primary key for this table.
This table has one ROW for each combination of ROOM X DATE for which there is relevant information. For each combination of ROOM X DATE that isn’t reserved at all, there is no row. So your algorithm would be like this:
(a) Request comes in to reserve ROOM123 for 2012-07-15.
(b) Look for the record with ROOM123 2012-07-15 in this table.
© If you find a record with this combination of data, it means THAT room is reserved on THAT date. Additional fields may be present in this record with other information that you considered relevant.
(d) If you don’t find such a record, then the room is not reserved on that day. In this case, you may make the reservation, and add a new record to the table, with ROOM123 2012-07-15, along with filling any other relevant fields.
(e) If a request comes to cancel an existing reservation, look it up similarly. If found, delete the record. (Or keep a record somewhere else that a reservation was made and later canceled, if you need to keep that kind of history.) If not found, respond that you can’t delete the reservation because there is no such reservation.
ETA: BTW, I suppose I should mention that this is a VERY STANDARD way to set up tables with this kind of information. I’ll add another post, just for illustration, showing a similar problem with a similar solution.