Потоки активности/каналы, чтобы денормализовать или нет?

Я знаю, что вариации этого вопроса задавались много раз (и я их читал, 2 из них были: 1, 2), но я просто не могу оборачивать голову тем, что просто похоже на правильное решение.

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

Я знаю, что этот вопрос очень ситуативен, поэтому я кратко объясню свое:

  • Многие действия, которые вызывают множество событий.
    • Следующее, создание, симпатия, комментирование, редактирование, удаление и т.д.
  • Пользователь может следить за другими действиями пользователя (события, которые они запускают).
  • Наиболее востребованные события будут самыми последними событиями.
    • Желательна возможность просмотра прошлых событий.
  • Нет сортировки или поиска в канале, желательно, чтобы прошлый заказ по дате.
  • Масштабируемость - это проблема (производительность и расширяемость).

В течение среднего времени я закончил работу с денормализованной установкой, состоящей в основном из таблицы событий, состоящей из: id, date, user_id, action, root_id, object_id, object, data.

user_id является тем, кто вызвал событие.
action - действие.
root_id является пользователем, которому принадлежит object.
object - тип объекта.
data, содержащий минимальный объем информации, необходимой для отображения события в потоке пользователя.

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

Это работает, но денормализация просто кажется неправильной. Аналогично, полиморфические ассоциации. Кажется, что Fanout находится где-то посередине, но чувствует себя очень грязно.

Со всем моим поиском по этой проблеме и чтением многочисленных вопросов здесь, на SO, я просто не могу заставить ничего щелкнуть и почувствовать, как правильное решение.

Любой опыт, понимание или помощь, которую может предложить любой, значительно оценены. Спасибо.

Ответы

Ответ 1

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

Лично я рассматриваю случай, когда я управляю отдельными таблицами применимых типов операций, таблицей ревизий/журналов для каждого из этих типов, а каждый из них ссылается на более центральную таблицу журналов событий.

Последний позволяет создавать фид и очень похоже на решение, с которым вы столкнулись: event_id, event_at, event_name, event_by, event_summary, event_type. (Поле event_type является varchar, содержащим имя таблицы или объекта.)

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

Вы можете получить интересную информацию, посмотрев вопросы, связанные с журналом аудита:

https://stackoverflow.com/search?q=audit+log