Databases are fine for this stuff, just make sure you use indexes and, if you can avoid usage of LIKE
open on both edges
wrong, it does not use indexes
where data like '%search%'
good, it uses indexes
where data like 'search%'
If you will have records counting over million, or long texts. You could break time in categories, and store them in different tables. This way you will tell the user to search in that category only.
Make sure that you implement the right on text change event + key timer, as you can end up to issue db requests for a search too soon, and the user has not finished typing.
In mobile/desktop environment a 300ms wait for next keypress is advised.
To explain what I mean: suppose you want to searc for "blueray"
- user types in "b" on text change fires, search is requested with like 'b%'
- user types in "l" on text change fires, search is requested with like 'bl%'
- user types in "u" on text change fires, search is requested with like 'blu%'
you will end up doing inefficient queries, that take long-long time
you should do:
- user types in "b", you should wait for 300ms for next key
- user types in "l", you should wait for 300ms for next key
- user types in "u", text reached length 3, allow the search