Ross and Andy,
That's really useful (and it will probably keep me quiet for a while)
Thanks for taking the time to help.
Cheers,
Ian
2008/11/7 Andy Freeman <[EMAIL PROTECTED]>:
>
> 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 google-appengine@googlegroups.com
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
-~----------~----~----~----~------~----~------~--~---
