2008/11/6 Jon Watte <[EMAIL PROTECTED]> > > > Wouldn't you have to use "NOT IN" to select the free spots in a regular > SQL database?
You can use an outer join and select only the records which have a null in a required field > > > And when you have 10 courts, 1,000 clubs, I don't see where the "10" > records are coming from If there are 10 bookings there are 10 records for the bookings, not 10 million or whatever > -- assuming the booking percentage is at least > 50%, then you'd have to consider 5,000 records even in the SQL case. But > if you index the records by club and then by time, and you know which > clubs are close enough to the user, then the number of records returned > should be quite manageable. Possibly. This was only an example to demonstrate the question. You can break any metaphor of you push it hard enough. Even so, I wouldn't imagine that if the book-ahead period were adequate for the needs, that the courts would be booked up for 50% of that date range. > > > Finally, there is a difference between "performance" and "scalability." > Roughly, if the runtime of an algorithm is k*f(N), then "performance" > attempts to reduce the k (which can be very useful), whereas > "scalability" attempts to push f into a lower complexity class (e g from > N-squared to N-log-N). You seem quite hung up on the "k" part, whereas > the "pre-create all records" solution is a solution to the "f" question. > There exists an upper limit to any single SQL server, so federated data > is the norm in enterprise data centers. The Google model isn't that far > away from the federated model in the degree of re-design you have to do > compared to the "naive" regular SQL schema. Mmm. Actually, I don't know what the f*k(N) hell that means, but it sounds very convincing. I'm sure you're right. > > > Finally, you can easily assume that "no record == free" if there is a > separate record saying what the opening times are for each club for each > day. That way, you can create the list of un-booked spots for each club > for a given time period using only a small bit of logic (basically doing > the final join yourself). That's pretty good, given that you then get > "infinite" scalability, IMO. I am *wanting* to assume that no record means no booking (the opposite is unworkable) and I really don't care if I have to add immense numbers of records full of null values to get the same effect that an outer join would give me in SQL, it just seems like a complete waste of space. I'd love to tell you what we are really talking about, but I can't. It's not just a few squash courts. 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. Ian --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
