Having given my view on structuring, I'll give me opinion on the problem. You're attempting to store information which at some point will be queryable on a wide variety of criteria, from spatially, cuisines, partial names matches etc. I would design a solution that respects these potential problems, but doesn't necessarily cater for them.
Assuming you're building a product that succeeds, it's a fair assumption you'll end up using elastic search (or something similar) at the end of the day. A good bridging gap for this is the full text search API, but it does have severe limitations which you will outgrow. You'll probably hack around them for a while first to keep your architecture with minimal moving pieces. I can almost guarantee you'll hit the edges of an indexed datastore entity very quickly. Composite keys are a killer for complexity, and will be required on any faceted search as soon as you permit sorting. I have actually done this before (specifically restaurant search), I was able to make assumptions about the locations based on the user, so they only had to supply suburb name. With a discrete list of cuisines and interesting factors (vegetarian, disabled access etc) the search api was enough. Introducing distance (restaurants within 10km of me) it was not, so that was the cutover point. -- 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 http://groups.google.com/group/google-appengine. To view this discussion on the web visit https://groups.google.com/d/msgid/google-appengine/db16a539-7916-458c-96a6-6205fc734c6a%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
