0

What is the best practice for this situation?

I am building a reservation system, and I'm looking at the best way to capture and store information from a user. Each resource is available for one day and can take any amount of users up to the maximum. So for example, say it's a hot air balloon with a maximum of 5 people. I want my form to look like this:

[Buttons to select # of guests]  // So if a user wants the same price for 1-3 people he only has to enter it once.

From [START DATE] to [END DATE]: [RATE]  // Where the []'s are input fields for the user

I plan to store each price in the database as:

Date, # of guests, rate

So one row for each date.

So I need to convert "[START DATE] to [END DATE]" to storing the values for each date. Should I do that client side in Javascript, or in my controller in rails? If the rates are the same for a set of guests, i.e. 1-3 guests, is there a way I can store that in the DB for better querying? Or should I not bother because if tomorrow the user wants to change the price for 2 guests, it might screw up my db.

marc_s
  • 732,580
  • 175
  • 1,330
  • 1,459
Tim Reistetter
  • 829
  • 1
  • 12
  • 17

1 Answers1

0

Start date and End date vs. Each date - several conditions:

  1. If the user wants to book a hot air balloon for 3 days, is it the same hot air balloon every day or can it change? If it can be different, have a resources.type field mapped to several booked_resources.id.

  2. You need to check for overlaps of resource usage if you use separate start and end dates. Storing repeated records one-per-date with the booked_resource.id would remove the need for overlap checks. See this thread for a related question: Storing Calendar Data in MySQL

  3. Sending the client-side JS an array of dates for each day can be more easy than extracting for each day between start date and end date. Pick whichever conforms best to your current code. Remember that either way, the SQL/date checking has to be modified to spot for unavailability.

  4. If a user can change the number of guests and that affects cost, then storing each individual date is more convenient for db updates of that kind (like the itemized billng by Hotels). Otherwise you would need to 'split' records for the dates which have different # of guests.

Community
  • 1
  • 1
aneroid
  • 12,983
  • 3
  • 36
  • 66