Question

Do you think it’s a good idea?

Like storing keywords from the real database inside a sqlite database, along with object IDs. SO when you search you do it with sqlite to get the IDs of the objects you found, and then query the real database using those IDs.

example object from the mysql db:

ID   slug       title        content
_____________________________________________________________________________
5    bla-bla    Bla Bla      I know what you did last summer

this would get indexed in the sqlite like:

ID   keywords
_____________________________________________________________________________
5    know, summer, last, what

or maybe

   keyword     objects
   _____________________
   know        5, 6
   summer      5
   lst         5, 7, 10
   ...

but you would get a huge database, probably with ~15000 entries considering the english vocabulary

Answer 1

The idea of a database is that it is capable of doing query operations very fast and efficiently.

SQLite on the other hand is a perfect tool for development purposes since you do not have to setup a db instance. However with it, comes certain down sides such as that it cannot handle many concurrent connections at once efficiently or at all.

Therefore the suggested approach in my opinion is not the best since SQLite would not be able to handle many queries and therefore defeat the whole purpose of the database.

It might be a lot better just to maintain a high performance db which would be able to handle all the queries. And there are usually tons of ways you can optimize a db such as mysql, postgresql, etc.

EDIT

Just a thought. Maybe breaking a string into words and treating them as keywords is not the best way. The problem is that the search will just return if a certain keyword was used somewhere in the system however that will not consider the context and the priority from where the keyword came from. I don’t know much about searching but having a some sort of rank system would seem to be beneficial.