Hey Karl! I definitely would leverage Google's API for this problem, but I actually was more interested in the approach for this hierarchical type of problem. To flatten or not to flatten, that is the question! But yes, APis would allow me to check for user error when it comes to cities and such. I think my current format doesn't allow me to figure this out efficiently. I would need to get the city, find neighbouring cities and then find restaurants in those cities.
Actually, I could submit their original query and ask some other api for nearby cities. Once I got cities I could also run queries for the same restaurant name in those neighbouring cities. Even better I think, would be when I create my restaurant information, I find the neighbouring cities using some other API, and create restauants there pointing back to the correct city... For instance City 1 and City2 are close to each other. When I put a restaurant via, Country, State, City1.Restaurant, I could also run a query through some other api for neighbouring cities. Once I get that information I could put the restaurant information into, Country, State, City2, Restaurant. Then if someone screws up and searches Country,State.City2.Restaurant instead of the correct City1 alternative, I would still be able to give them information that points back to the correct city. This means extra time for creating data, but hopefully less for searching through it. Thanks Karl! On Monday, August 17, 2015 at 5:41:25 PM UTC-7, Karl MacMillan wrote: > > > > On Sunday, August 16, 2015, Sanket More <[email protected] <javascript:>> > wrote: > >> Hey Nick! >> >> After I submitted my question, I went through lots of information sources >> and gathered some information. >> I feel like my question was based on many misconceptions about google app >> engine's datastore. >> >> I think I have a strategy for the restaurant problem. >> The user will provide me with country, state, city and the restaurant >> name, And I will provide the user with location(s). >> >> So all I really need is one specific entity and the response will simply >> be the information in that entity. >> And, I don't really need to index country, state, city, and restaurant >> name with each other independently. I just need one string that holds the >> country state city and restaurant. >> In fact, I think that string is unique. >> So, I am thinking about having a restaurant kind with key string >> "country_state_city_restaurant" >> >> Once the user has finished submitting the form, I can get by >> "country_state_city_restaurant" and return some information to the user. >> >> I wanted a smarter solution than this, because I feel that this solution >> won't scale well. >> Furthermore, if I am flattening my tree structure like this, wouldn't gql >> be faster? >> >> >> On Sunday, August 16, 2015 at 4:14:33 PM UTC-7, Nick wrote: >>> >>> The general rule is optimize for your primary use case, denormalise to >>> support others. >>> In addition, enforce and support constraints In your code. >>> >>> If your primary case is restaurant search, embed and index all necessary >>> data. This will be the fastest solution and easiest to work with >>> >>> On Appengine extra data doesn't cost you unless it's indexed. There is a >>> careful balance between optimising for speed, cost and transactional >>> integrity. My advice is if this is your first go, expect to make mistakes >>> and to need to reengineer your data a couple of times. Make that process as >>> easy as possible. >>> >>> > Just a suggestion - have you thought about letting the user query through > the Google maps or similar API to find the restaurants and then based on > those results returning information from your app? These location based > queries are hard - both technically and from matching the users > expectations. Especially as I'm betting that the city that a user thinks a > restaurant is located in often differs from official addresses, especially > in large cities. > > This strategy could let you both control the user experience and leverage > the hard work of others. > > Karl > > >> -- >> 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/04705cc7-3673-4d82-984a-61c64b099fe8%40googlegroups.com >> >> <https://groups.google.com/d/msgid/google-appengine/04705cc7-3673-4d82-984a-61c64b099fe8%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> For more options, visit https://groups.google.com/d/optout. >> > -- 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/9463822a-568a-4483-9319-fbf78b80f61a%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
