> > > SQL databases are great at hiding really horribly-inefficient queries.
That's fine with me. I don't mind them being hidden if the alternative is that I have to write my own even more really horribly-inefficient code to get things done > > What "scalable" means is often hard to see on a traditional SQL > database, since its "simple" queries are really turning into big table > or index scans behind the scenes. It requires a good DBA to keep that > scalable. Well, 1000 clubs with 10 courts and 24/365 and one booking means 1 booking record in a traditional SQL database. It's hard to see how this is really horribly-inefficient when compared to checking 100 million records to find the one used booking if I do it the way some people are suggesting here. For other scenarios, I'm sure the reverse is true, but Google developed BigTable for a very specific need, i.e. shoving complete web pages into a big table whereas relational databases have been developed over many more years and had many times the resources used on them to produce a general-purpose database system. BigTable is not designed for many of the tasks that relational databases *are* designed to do and relational databases are not designed to index every web page on the planet. 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 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 -~----------~----~----~----~------~----~------~--~---
