How would you design a table for a booking system?
If the concern is manual maintenance of a large number of rows, you could solve this (potentially) by creating tables for each of your dimensions: weeks, time slots, and venues.  The complete set of possible slots for booking would be the cross product of these three dimensions. Actual bookings would be another table with foreign keys pointing to all three of these dimension tables.   

With this type of design, instead of maintaining 3 x 25 x 26 records you will maintain 3 + 25 + 26 records.  Note that if you segregate day of week and time of day into two tables you can reduce the number of records to be maintained even further (3 + 5 + 5 + 26).

The problem with this approach is when (and if) you have an exception.  This design assumes that there are no blackouts in your schedule.  For example, what if you close a room for a couple of weeks to be renovated?  One way to handle this issue is to create booking records that cover the blackouts.  If you have enough exceptions, then managing them may be almost as bad as just using the brute force method.

The question I would seriously consider is whether or not generating the initial list of slots available for booking is really that big a deal.  You could easily automate the  process to generate your big pile of available slots.  This is really just a single query.