I want to show users a history of their searches, which can often be complicated:

  • any of these terms: [a,b,c]

  • all of these terms: [d,e,f]

  • not these colors: [h,i,j]

Since these searches are done through a UI (not a search input where they would type "a OR b etc...") I assume I would need to store each value in a table.

Would it be overkill to create a table for each facet ("search_terms", "search_colors", etc)? or is there a simpler way?

| search_id |   term(_id)  | operator(enum)|
| 1         | blue         |     any       |
| 1         | green        |     any       |
| 1         | red          |     any       |
| 1         | musthave     |     all       |
| 1         | exclude_me   |     not       |
| 1         | exclude_also |     not       |

Some other considerations are:

  • The web-URL can change over time, so I don't want to store that as an easy way out.
  • The index/3rd party service I'm searching could change, so I similarly can't save the query I make.

(The terms themselves can be its own table with a reference instead).

2 Answers 2


What you store should mimic what the user sees in the UI. That way you can present it in a format that is familiar to him.

This format may, or may not, be anything close to the SQL that has ANDs and ORs.


You need to look at the way the UI sends the search to server and attempt to duplicate this data. Since you are using a 3rd party search engine I assume that you can configure it search text for specific terms and as a result you should be able to store the data search by search (all the info in one field). Probably with the exception of the user id (to restrict how's searches a user can search) and search id (primary key).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.