Столкнулся с проблемой.
На сайте есть объект, к примеру, человек.
По нему есть стандартная информация, типа год рождения, пол и т.п.
Так-же на сайте есть фотоальбом, список мест куда можно ходить (клубы и т.п.), статьи, новости и т.п.

Задача, чтобы при просмотре информации о данном человеке, показывались вся информация которая встречается о нем на сайте.

Я хочу решить проблему так:
Фотоальбом - ключевые слова к альбому/фотографии
Места - выборка из списка людей, которые посетят, посещали Место.
Новости/статьи - поиск в теле статьи/новости + ключевые слова.

Самому объекту задать набор поисковых слов - Имя, Фамилия, Никнейм.

Для базы нагрузка большая получается, следовательно надо кэшировать информацию с обновлением раз в сутки.


Может быть есть другие пути решения задачи?

Два основных пути:

1. Непосредственно при вводе указывать всю контекстную информацию (все связи между объектами) -- естественно, при активной помощи CMS
2. Вводить минимум информации и заставлять CMS восстанавливать подразумеваемые связи между объектами.

Ты описал одно из частных решений для второго способа. Правда термин "кэширование" здесь не вполне уместен. Задача ресурсоемкого процесс, запускаемого раз в сутки или чаще, состоит просто в извлечении фактов из контекста.

Факты можно хранить, к примеру, в следующей простой форме:

1) Сущности: персона, альбом, место и т.п.
2) Типизированные связи между сущностями. Каждая связь имеет источник, цель и тип. Например: (#123, #234, "Присутствовал на"), где #123 есть ID персоны, #234 -- ID мероприятия, а "Присутствовал на" -- вид связи.

Соответственно, мы легко получаем список всех, кто присутстовал на данном мероприятии или всех мероприятий, которое посетило данное лицо. Несложно строятся и более интересные запросы.

Первый способ ввода предполагает, что связи и сущности мы создаем под контролем оператора. В частности -- просто вручную. В простейшем случае оператор открывает карточку мероприятия, нажимает кнопку "Добавить участника" и выбираем из списка "Иванов Иван Иванович".

В более сложном случае при вводе новости система по вхождению подстроки определяет, что в списке есть "Концерт на Красной площади" и "Иванов" (оба объекта уже существуют в БД) и предлагает оператору добавить их к объекту "Новость".

Второй подход предполагает, что мы вводим только информацию о сущностях, а связи система проставляет сама. Если не покушаться на семантический анализ текста, то остается только описанный тобой вариант с ключевыми словами.

В этом случае ручной работы меньше, но система периодически будет устанавливать "парадоксальные" связи. К примеру, наличие однофамильцев может приводить к курьезным ссылкам. Было у меня такое -- когда новость про какого-то правительственного деятеля залинковалась на однофамильца из мира бизнеса. А могло и на какого-нибудь уголовника.

Так что я личнот предпочитаю первый подход -- благо, есть много способов автоматизировать работу оператора.

Огромное спасибо
Буду делать.