One thing that makes the datastore stand out is that it doesn't store meta data about your kinds. Thats's why there isn't a limit to the number of entity kinds or namespaces you can have. 200 kinds is no problem from that perspective.
Namespaces make your life much easier. Your 2nd approach is pretty much what appengine does on the inside when you use namespaces. The limit on custom indexes is a serious problem however. Our solution was to not use them at all. We use single indexed properties instead and manage our composite indexes on top of that. That's much less pain than it may sound at first. To become a happy datastore user you must overcome relational thinking. There's more to it than to just stop thinking in terms of "tables". You should design for a more coarse-grained data scheme. In general that means identifying the entities that will almost always be used together - like an order and its order items. Store them as closely together as you can. Entity groups are a good start but also take a look at embedded entities. What we did is to store all business data as JSON Blobs inside entities and use regular properties for the *sole* purpose of indexing. That has been working out *very* well for us. Regards, Wolfram -- You received this message because you are subscribed to the Google Groups "Google App Engine" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/google-appengine. To view this discussion on the web visit https://groups.google.com/d/msgid/google-appengine/de93c24c-f2eb-4300-9104-8c17f6b10459%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
