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 -~----------~----~----~----~------~----~------~--~---
