ГУРУ, помогите советом: "Прочитанные сообщения"
Как следствие: Много пользователей и много сообщений.
Через некоторое время всю эту дребидень придется переносить с MySQL на Кассандру, но пока реляционная БД.
Как одна из необходимых вещей, которая должна сопутствовать сервису это возможность видеть новые сообщения. Иначе можно легко потеряться. (Или я не прав?)
Поскольку сообщения могут показывать как угодно и где угодно нельзя сделать просто проверку по дате последнего захода.
Как я вижу единственное решение: Помечать КАЖДОЕ сообщение КАЖДЫМ пользователем о его прочитанности в нормализованной таблице: (ид_сообщения, ид пользователя) = примари индекс.
Т.е. наличие строки в таблице говорит, что оно прочитано, отсутствие, что нет.
Эта таблица подключается ЛЕФТ Джоином к самой таблице сообщений и все выводится одни МАХОМ:
Как пример:
Вопрос:
1. Есть ли альтернативные, более быстрые решения?
2. На как долго такого решения хватит? (Я его применял на более маленьких системах, где там 20 пользователей... Но тут...)
3. Кто разбирается: Как быстро сервак не выдержит такие запросы сортировки? (Intel Dual XEON, 8 ядер, очень быстрые диски).
4. Может надо как-нить по особенному индексы организоввывать?
Заранее спасибо!
сеанс #: n
id - 1 time: 100
id - 2 time: 120
id - 3 time: 121
как видим, самое свежее сообщение c id: 3. Запоминаем его для данного пользователя.
сеанс #: n+1
id - 1 time: 100
id - 2 time: 120
id - 3 time: 121
id - 12 time: 10025
id - 30 time: 10100
id - 35 time: 10230
как видим, у сообщений с id 12, 30, 35 время больше, чем у id 3, значит они новые. Можно было бы просто ориентироваться на id, но при таком подходе можно сохранять время внесения правок и так же их отображать как новые или обновлённые сообщения
.
Новое сообщение = Сообщение, которое еще не было просмотренно Вами с момента последнего сеанса
Ромик:
Гениально! Создать таблицу сеансов на каждую страницу, где сообщения выводятся. Ибо даже по ИД проверять ГОРАЗДО быстрее чем по датам (я прав?)
Единственная проблемка это стена: В ней идет поток всех сообщений, в которых "мы принимали участие". Т.е. там может отобразится ответ пользователя А на ваш комментарий С для картинки Х.
При этом пользователь Б может тоже оставить комментарий для картинки Х, и притом раньше чем пользователь А. (1.С, 2.Б, 3.А). Но на стене это не отобразится (если картинка не принадлежит вам)
Но если сделать стену как отдельный "сеанс" этой проблемы не будет. Просто пометку "новое сообщение" на стене и "новое сообщение" на картинке придется повторить (ибо два разных сеанса, хоть одно и тоже сообщение).
Что может даже и лучше, ибо на стену мало кто смотрит
делает такое решение чутка не доработанным в случае с Фидбаком, поскольку Сообщение 123 может быть в "картинке" 1, а сообщение 121 в "картинке" 2. И получится если пользователь посетит картинку один, то даже никогда не посещая картинку 2, все равно сообщения в ней станут прочитанными. Как решение (все что написано выше, только в двух словах и проще) это ДА! именно использовать LastViewedID, только в отдельной таблице в виде:
UserId, LastViewedID, ImageID
Где указывается, что к примеру в картинке 1 мы видели последний сообщение 123, а к примеру в картинке 2 сообщение 120.. И тем самым "новое для пользователя" сообщение 121 будет правильно воспринято.
Но единственное, что вместо ImageId в моем конкретном случае будут использоваться (Object, ObjectID) как один Индекс.. Поскольку кроме "картинок" там будет еще куче других плюшек, которые тоже можно будет комментировать.. К примеру тот же PHP код =)
Edit:
Ах да.. Сорри. Это очень правильная мысль. Сортировка именно по дате изменения.