duncan.booth at invalid.invalid
Fri Mar 5 10:07:49 CET 2010
Gregory Ewing <greg.ewing at 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
>> internal use) is Google App Engine and that apparently uses one
>> 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
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
>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
More information about the Python-list