Staff's solution of search doesn't pass required tests. Mine does, but works much slower

Question

As per specifications we are given links to test return of JSON data for our search requests.

But staff's solution doesn't pass them. Check, only first one returns something.

http://pset8.cs50.net/search?q=02138

http://pset8.cs50.net/search?q=Cambridge+MA

http://pset8.cs50.net/search?q=Cambridge,+MA

http://pset8.cs50.net/search?q=Cambridge,+Massachusetts

http://pset8.cs50.net/search?q=Cambridge,+Massachusetts,+US

or

http://pset8.cs50.net/search?q=06511

http://pset8.cs50.net/search?q=New+Haven+CT

http://pset8.cs50.net/search?q=New+Haven,+CT

http://pset8.cs50.net/search?q=New+Haven,+Connecticut

http://pset8.cs50.net/search?q=New+Haven,+Connecticut,+US

I've designed solution (I can show if asked and it is reasonable to show), that passes all of them and even more sophisticated requests.

1. It parses q request into separate words, irrelevant of separation via space or commas
2. It accounts for situation when user input middle of word or when place name consists of two or more words (otherwise, if you search for New Haven and Haven is separate word in Select it wouldn't return New Haven because it counts them as single string. And it doesn't seem reasonable to implement separate moduls to check which part of q entry might be related to city name, which is to state, etc).
3. It clears out with each Select by each word only those results that satisfy everything user entered (i.e. if he wrote New CT it will show all places with New in it's name located in CT, similar with Haven CT).

Basically it makes SELECT statements for each word user entered and cross-references everything, leaving in final list only items that appear in every SELECT statement.

But... It takes too long to execute, so it results in suboptimal user experience. it can take 10 or more seconds before any suggestion is shown.

So I have two questions: - Shall I disregard tests that requirements suggest and make sure my solution gives same results as staff's one? - Is there any way to make less computationally exhaustive search that still will work for Okay user experience. May be you can give me some reference what to read or to learn to get better in such tasks?

Answer 1

I don't think those are required tests; the pset has no check50 and the spec does not include links to a staff version for those tests. From the spec:

Again, though, we leave it to you to decide just how supportive /search will be of such variants. The more flexible, though, the better! Try to implement features that you yourself would expect as a user!

As a user, if I was searching for "New Haven, Connecticut", I would start typing and expect results by the time I got to the "v" that I could scroll through before I tried to remember how to spell "Connecticut" (which would happen with a simple q like place_name + %).

"Shall I disregard tests that requirements suggest and make sure my solution gives same results as staff's one?". Since they are suggestions, decide which ones seem reasonable as user input and work with those. There is no reason to make sure your solution gives the same results as staff: the pset doesn't require it, and it's unlikely that you could. You cannot know what query(ies) are being used. You can't even know if staff solution uses the same places data (it doesn't!). Don't code to these specific examples, code to your expectations as a user.

Is there any way to make less computationally exhaustive search that still will work for Okay user experience. Be the user. Will you actually type "Massacusetts" after "Cambridge", or will you scroll through the results to pick? I think this calls for KISS - Keep It Sweet and Simple. Perhaps consider City, State, Zip (the placeholder in the typeahead box) "instruction" to the user as to how to format input and code to that.

There are other challenges that lie ahead in this pset. And (maybe I KISSed it to the extreme), but the main thing is getting some results do you can proceed.