First, they need a way to do mass updates stil, since you can only fetch 1000 at a time, and doing so many updates in that manner is *really slow*. You will run out of time and Google will kill your request. In the meantime, the best you can do is some sort of AJAX page where it then triggers all the other hits that try to load subsets of products and update their names. Either way, its still really messy right now.

Second, with regards to storing a customers data. You’re missing the important bit about Entity Groups and ancestor keys. If you have a batch of customer data that you need to work with at one time, you should ensure that the entities are keyed to the same ancestor.

This allows you to:
a) ensure that all the data you want to get to for a specific customer is stored in the same portion of the distributed database.
b) do transactions that wrap the whole group of entities
c) update multiple entities in a single put() statement

There’s definitely a lot to consider with BigTable.

A simple explanation is that normalisation attempts to remove all duplication between data in tables.
Thats the thing that makes you want to put customer information in a customer table, order information in an order table and create relationships between them.

This is what we’ve done for nearly 30 years now, so it’s become second nature to us.

However, sometimes we realise that it will cost more to do the join on the two tables when we want to query it than we save by seperating the data.
We’ve recently had an example of that at my work, where we discovered that in order to select about 10 items from our database of nearly a million items, it had ot join all those million items into about 5 tables because the where clause relied on properties on multiple tables.

The solution then is to go the opposite way to normalisation, to denormalise. This means that we copy data from our end tables, often into the join table, which means that the database can be more efficient, limiting the join table first, and then performing the join.

Finally, Google AppEngine does have foreign keys, at least in the django model anyway, and they’re called ReferenceProperties.

Hope that helps

OK, I’m doing my best to ‘empty my mind’, and here are my realizations:

1. So, there are really no ‘foreign keys’, in the sense of Customer = Customer_id(5)?

2. Then, my customer_name will be written all over the place in different tables - that’s denormalization?

3. If I want to track projects-persons, I have to make a list property with the projects ['house', 'office', 'street'], instead of a join table.

4. And I really have to rethink my database design with the business logic of queries governing all.

It’s really a return to a much more naive state of how databases were done ‘back in the day’.

Thanks!