Online travel agent database design (rates table) for hotels in mysql

Question

I have developed a system to manage hotel rates, allotments and bookings using php and mysql for a travel agent with round 150 hotels. As the hotel room rates differ by date table design is as follows roughly

hotel_tbl{
 hotel_id,
 hotel_name
}    

room_type_tbl{
 room_type_id,
 room_type_name,
 hotel_id 
}


room_rates_tbl{
  room_type_id,
  **from_date,
  **till_date,
  meal_basis,//(Breakfast,halfboard,fullboard) BB,HB,FB
  sleeps,//(Single,Double,Triple) SGL,DBL,TPL
  currency,
  room_rate
}

As the hotel rates fluctuate by date i noticed when I query the table for complex tour package calculations(involving multiple hotels) the performance is slow than expected. My question is do you think the performance can improve if I have a rate row for each date instead of using a date range (my system contains around 150 hotels) something like below:

room_rates_tbl { // A row for each day as opposed to using a date range
  room_type_id,
  **date,
  meal_basis,//(Breakfast,halfboard,fullboard) BB,HB,FB
  sleeps,//(Single,Double,Triple) SGL,DBL,TPL
  currency,
  room_rate}

Hope the question is clear enough...

I have updated my question to make it more clear. Room Type is for example "Standard Room" or "Deluxe Room" or "Family Room", Sleeps would contain whether its a Single,Double Etc. I have removed the market_type from the question as it is not relevant it was meant for market group(such as countries) the rate is targarted at. My question wether was storing rates for date can be more efficient than using date ranges when it comes to quering the rates table.

Answer 1

Let's assume that your query is for a particular type of room for all hotels between two given dates. What do you need to get from the database? I would suggest:

1. The rate for that type of room for all hotels on the start date
2. The rate for that type of room for all hotels on the end date

You want avoid table scans, because these slow down your response to the user. So any lookup needs to use an index. Since the query is based on dates, the date field should be indexed. So if the user wants a room between 31/12/12 and 05/01/13, we can use range operators over the index as described in http://dev.mysql.com/doc/refman/5.1/en/range-optimization.html#range-access-single-part ). (If you store the date value as a timestamp value, you reduce the storage size of the values, which should improve the performance of the index.) If you use your original table schema, you'll need two indexes - one on start date and one on end date - but fewer rows in the table, compared with the amended table you suggest, which will need one index but more table rows (one for each day etc.) It's too variable to suggest which one will perform better.

Answer 2

I think it will be better to separate your date & rate into another table.

room_tbl - room_id , room_type_id, market_type_id & whatever room information

room_rate_tbl - room_id , from_date, till_date, currency, room_rate

This way your room information is independent and you can easily add, edit, remove any room rate to a particular room_id.