Gregory Ewing <greg.ew...@canterbury.ac.nz> wrote: > Duncan Booth wrote: >> Did I mention that bigtable doesn't require you to have the same >> columns in every record? The main use of bigtable (outside of Google's >> internal use) is Google App Engine and that apparently uses one table. >> >> Not one table per application, one table total. It's a big table. > > Seems to me in that situation the term "table" ceases to > have any meaning. If every record can have its own unique > structure, and data from completely unrelated applications > can all be thrown in together, there's no more reason to > call it a "table" than, say, "file", "database" or "big > pile of data". > I think it depends on how you look at things.
AppEngine uses a programming model which behaves very much as though you do have multiple tables: you use Django's programming model to wrap each record in a class, or you can use Gql query languages which looks very similar to SQL and again the class names appear in the place of table names. So conceptually thinking of it as separate tables make a lot of sense, but the underlying implementation is apparently a single table where records simply have a type field that is used to instantiate the proper class on the Python side (and another hidden application field to prevent you accessing another application's data). Also of course records with the same type still may not all have the same columns if you change the class definition between runs, so even at this level they aren't tables in the strict SQL sense. There may of course be other applications using bigtable where the bigtable(s) look much more like ordinary tables, but I don't know what they are. >From your suggested terms, I'd agree you could call it a database rather than a table but I think it's too structured for "file" or "big pile of data" to be appropriate. -- Duncan Booth http://kupuguy.blogspot.com -- http://mail.python.org/mailman/listinfo/python-list
