Google App Engine Datastore

The Google App Engine datastore (DS) has advantages and disadvantages, both of which will greatly affect how you formerly design a relational database (DB).

1. Don't store anything useless.
2. DON'T store anything useless.
3. Don't store anything massive.
4. Everything needs to be indexed to be found. Composite indexes (searches involving more than one field) are expensive to store, so avoid them unless you are sure these composite fields will remain small.
5. Don't create useless indexes.
6. Reads cost money, and writes even more. You can't write everything for the sake of it; you can't read everything straight from the DS. Memcache is your friend, but make sure it is kept fresh.
7. There are no primary keys. You can easily duplicate something by accident.
8. There are no unique fields. To implement a unique field, you need to fetch every object saved from the past to make sure nothing is already there.
9. Indexes don't rebuild themselves. If you create a new index, it will not contain any information about objects already there.
10. There are no relationships. Joins are impossible. Many-to-many relationships are hard-coded. The DS understands none of that stuff you used to trust MySQL to do.

When to use the Expando class

When your model has lots of sparse properties that aren't meant to be searched, you should use the Expando class. Sparse properties are analogous to sparse tables, where only a few columns in all rows contain information.

Examples

• Users (who may have random addresses, phones, postal codes... almost none of which will be providing us with all the information we want to have)
• Apps (you know there will definitely be some set amount of information that should be in this class, but you aren't sure if this list will be expanded)

When not to use the PolyModel class

PolyModel stores class and subclass information as a StringListProperty, consuming lots of space (mind you, they also require primary indexes). Never PolyModel large quantities of information.