Второй вариант - создавать свой собственный поисковый индекс (таблицу), в которую заносить список слов для каждого текста, хранящегося в BLOB-е. Список слов (поисковый индекс) в этом случае придётся создавать, естесственно, самому.

Плюсы такого решения:
1. Независимость от механизмов СУБД, т.к. поисковый механизм сделан собственноручно на основании функционала, предоставляемого самой СУБД;
2. Если оставаться в рамках стандарта языка SQL, то если понадобится перенос на другую СУБД значительно упростится.

Минус, по моему один:
1. Рост объёмов БД - поисковые таблицы штука прожорливая.

В качестве обоснования вышесказанного могу сказать следующее. В нашей фирме разработана собственная информационно-аналитическая система, в которой поисковый механизм устроен именно таким образом. Объёмы баз, которые на ней вертяться, колеблются в районе от 0.5 гигабайта до 1.8 гига. Система работает уже 4 года и на протяжении всего времени устройство поискового механизма в ней остаётся неизменным. Система успешно продаётся.

Если будет интересно, Mayor, пиши в форум или на мне мыло оно под ником.

Ну так и заноси ВСЕ слова текста в поисковую таблицу. И будет теье поиск не по ключевым словам, а полнотекстовый.
И что значит "контекстный"? Поконкретнее можно?

Mayor RedborНу так и заноси ВСЕ слова текста в поисковую таблицу. И будет теье поиск не по ключевым словам, а полнотекстовый.
Это, по сути, то же самое, что предлагает Мимопроходящий.
Не совсем. Точнее, СОВСЕМ не.
Если ты будешь хранить весь текст в одной строке, то при поиске ничего, кроме tablescan-а не получишь, на индексы и не надейся. Да, это будет полнотекстовый поиск, но ОЧЕНЬ медленный.