Ако искаш изключително бързо, ама за 1-2 сек.
това се прави с 'reverse index', 'inverted index' или поне така го наричаха. Така работят търсачкие (Гого например.). Обаче за реализация е досто трудоемко.
правил съм такова нещо: (и още го правя
)
Идеята е следната. Прави се една таблица, в която са описани всички (уникални) думи които се срещат в базата.
това са мойте таблици (само за идеята):
mysql> describe word_index;
+-------+-----------------------+------+-----+---------+----------------+
| Field | Type | Null | Key | Default | Extra |
+-------+-----------------------+------+-----+---------+----------------+
| id | mediumint(8) unsigned | NO | PRI | NULL | auto_increment |
| word | varchar(32) | NO | MUL | | |
+-------+-----------------------+------+-----+---------+----------------+
2 rows in set (0.00 sec)
и се прави още една таблица в която пък се описват всяка уникална id=word_id дума в точно кой продукт се среща. (offerta_id е при мене, при теб е продукт_id). (weight и su_weight са си мои теглови коефициенти, вместо тях може да е нещо друго или изобщо да ги няма)
mysql> describe search_index;
+------------+-----------------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+------------+-----------------------+------+-----+---------+-------+
| word_id | mediumint(8) unsigned | NO | MUL | 0 | |
| offerta_id | int(10) unsigned | NO | MUL | 0 | |
| weight | tinyint(3) unsigned | NO | | 0 | |
| su_weight | tinyint(3) unsigned | NO | | 0 | |
+------------+-----------------------+------+-----+---------+-------+
4 rows in set (0.00 sec)
при търсене, това което подава клиента пак се разделя на думи , виждат се кои са уникалните думи word_index и по тях и по втората таблица се виждат в кой продукт се срещат.
Обаче куерито за самото търсене е много заплетено (Но пък е много бързо). Според зависи от нуждите. То например може да брои броят съвпаденията на думите в стринга, може да изчислява някакъв тегловен коефициент и т.н. Според зависи.
Това е идеята....Обаче не впускай да го правиш, че е занимавка за години.
Недостатък е че при всяка промяна на текста в някой продукт, трябва наново да се изграждат, двете таблици. Аз съм си направил един скрипт, дето се пуска всяка нощ. Недостък е че през това време, промените не се отразяват на търсенето, и клиента ще вижда старите резултати. Е те този скрипт е тежкият и върти поне 30 мин.
Досега не ми е стигнало времето да го направя, таблиците да се обновявят динамично.
Друг недостатък е че това е 100% съвпадение на отделните думи. Не е levenshtein() или soundex() .... Но мисля че може така с този 'reverse index' да се пригоди и по този начин.
––––––––––
ПС: А колкото до regex. preg_* на PHP-то работят много бързо. Може да е даже по-бързо и от grep-a.
