class FreeCourt(db.Model):
{denormalized court info so you don't have to join to restrict
courts appropriately}
start_date = db.DateProperty(required=True)
free_hours = db.ListProperty(int)
There can be one record per quantum, which is a day, a week, a month,
or whatever is convenient. (You've got to look out for exploding
indices.) free_hours is a list of the hours starting at start_date
when the court is available. For example, if there's a record for
every day and a given court is available from 6am to 9pm, free_hours
initial value is [6..17]
To find a court that is available at 10am,11am, and 2pm on a given
date, the time part of the query looks like "free_hours = 10 and
free_hours = 11 and free_hours = 14".
If you use court location x start_date to define entity groups, you
can even use a single transaction to book all of a customer (or
group's) activities within the relevant time period at said location.
(In other words, their meal, spa, and golf reservations as well as
tennis. Restaurants are a little tricky because they have lots of
tables, so I'll leave them as an exercise for the reader.)
On Nov 6, 5:16 pm, Jon Watte <[EMAIL PROTECTED]> wrote:
> Ian Bambury wrote:
> > I know I can reduce the number of records required by having a
> > hierarchical structure of months/weeks/days/hours or whatever and then
> > create dummy records if I need them, and write all the code to work
> > out that if I can get the year record and then I can get the month
> > record and then I can get the week record but I can't find a day
> > record then the hour I want is free and then moving on the the next
> > health club or whatever and doing it all again and again and again
> > until I have enough results to display, but it seems such a pain in
> > the arse compared to just having records for actual bookings and
> > making one query to get back a list of the next n free slots.
>
> If we assume a 50% occupancy percentage, and you have all the records in
> one big table, then how many simultaneous users can your SQL server
> handle before bogging down? Chances are, the distributed database way of
> doing it will perform a lot better when there are many, many users using
> the system all the time, for a reasonable dollar cost. And chances are
> that Oracle might not be able to sell you a big enough database to scale
> to the same number of users, at any cost.
>
> So, which is more important? Formulating the query using the tools you
> already know, or being able to scale to millions of simultaneous users?
> You can't get anything for free, but you can do what you want on Google
> apps, and reap the alleged scalability benefits.
>
> Sincerely,
>
> jw
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Google App Engine" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/google-appengine?hl=en
-~----------~----~----~----~------~----~------~--~---
