MySQL LIKE alternative

Question

Is there an alternative for LIKE. Note I cannot use FULL TEXT Search.

Here is my mysql code.

SELECT * 
FROM question 
WHERE content LIKE '%$search_each%'
OR title LIKE '%$search_each%'
OR summary LIKE '%$search_each%'

Answer 1

Well, MySQL has regular expressions but I would like to ask you what the problem is with multiple LIKEs.

I know it won't scale well when tables get really large but that's rarely a concern for the people using MySQL (not meaning to be disparaging to MySQL there, it's just that I've noticed a lot of people seem to use it for small databases, leaving large ones to the likes of Oracle, DB2 or SQLServer (or NoSQL where ACID properties aren't so important)).

If, as you say:

I plan to use it for really large sites.

then you should avoid LIKE altogether. And, if you cannot use full text search, you'll need to roll your own solution.

One approach we've used in the past is to use insert/update/delete triggers on the table to populate yet another table. The insert/update trigger should:

• evaluate the string in question;
• separate it into words;
• throw away inconsequential words (all-numerics, noise words like 'at', 'the', 'to', and so on); then
• add those words to a table which a marker to the row in the original table.

Then use that table for searching, almost certainly much faster than multiple LIKEs. It's basically a roll-your-own sort-of-full text search where you can fine-tune and control what actually should be indexed.

The advantage of this is speed during the select process with a minor cost during the update process. Keep in mind this is best for tables that are read more often than written (most of them) since it amortises the cost of indexing the individual words across all reads. There's no point in incurring that cost on every read, better to do it only when the data changes.

And, by the way, the delete trigger will simply delete all entries in the indexing table which refer to the real record.

The table structures would be something like:

Comments:
    id          int
    comment     varchar(200)
    -- others.
    primary key (id)

Words:
    id          int
    word        varchar(50)
    primary key (id)
    index       (word)

WordsInComments:
    wordid      int
    commentid   int
    primary key (wordid,commentid)
    index       (commentid)

Setting the many-to-many relationship to id-id (ie, separate Words and WordsInComments tables) instead of id-text (combining them into one) is the correct thing to do for third normal form but you may want to look at trading off storage space for speed and combining them, provided you understand the implications.