Какие нынче существуют готовые OpenSource системы уведомлений (нотификация) или переписки на сайте?

Ничего нет. Я сам писал.

Ничего нет. Я сам писал.

Что можешь сказать про реализацию?

Делал какую-то таблицу с очередью сообщений, в которой хранились данные типа:

- От кого
- Кому
- Текст
- Флаг прочитано

Если так, то что делал с рассылками «от администрации»? Как помечал флаг «прочитано»?

Или у тебя для каждого пользователя своя очередь сообщений, и соответственно текст при рассылке «всем» дублируется каждому получателю?

Хочу вот таких вот подробностей.

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

SHOW FIELDS FROM имя_таблицы

Как-то так.

Это пишется за пару часов реально. Ну вообще ничего сложного нет. Вот реалтайм-чатик - там да, есть где развернуться :)

Я в качестве тестового задания давал написать PM

Я плясал от собственного представления как работает связка почтовый сервер-клиент. Хотя оно могло быть и прямо противоположно действительности.

Таблиц нет и БД нет, т.к. «почтовый ящик пользователя» это папка на диске. Туда в разные папочки (входящие, исходящие и пр.) падают текстовые файлики.

Что касается общих рассылок со стороны администрации. Есть папка с сообщениями (ты назвал ее «очередь»). Каждое сообщение (файл) в ней имеет уникальный сгенерированный ID (имя). При «просмотре» своего ящика пользователь в том числе тягает список файлов рассылок. Получив список файлов он сверяется со своим «списком прочитанного», если ID нет в этом «списке прочитанного», значит «письмо» помечается как «непрочитанное».

Список непрочитанного это грубо массив уникальных идентификаторов (их надо где-то хранить). К примеру, в этом списке есть такие ID: k23, k45, k46 (три штуки). Получаем список рассылок. В том списке 4 письма: k23, k45, k46 и k51. Значит письмо с ID=k51 помечается на страничке как непрочитанное. Когда пользователь на него тыкается, k51 пишется в «список прочитанного».

Это пишется за пару часов реально.

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

Неверю(с)

Вот если бы сказал пару дней...

На серверной стороне это пишется действительно меньше чем за день. А вот с UI-кой можно мудрить до посинения :)

Получив список файлов он сверяется со своим «списком прочитанного», если ID нет в этом «списке прочитанного», значит «письмо» помечается как «непрочитанное».

Получается, что список прочитанного для каждого пользователя будет бесконечно разрастаться. Это походу явная ошибка в проектировании, не?

Зря не веришь)) Ну хотя судя по тому, что ты расписал, ты поклонник сложных велосипедов с квадратными колесами

Это только описание по памяти. Подумай над тем как избежать бесконечного роста списка...

ты поклонник сложных велосипедов с квадратными колесами

Хорошая игра, мне тоже нравится.

Это пишется за пару часов реально. Ну вообще ничего сложного нет.

Может намекнешь как выглядит велосипед с круглыми колесами?

У меня на прошлой работе тим-лид был такой.

Я тут самое сложное на сервере написал, а тебе теперь только интерфейс прикрутить.

А вообще у меня была самая обычная ситуация.

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

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

А вообще подписался, может кто и правда круглее моих колеса предложит.

Может намекнешь как выглядит велосипед с круглыми колесами?

id | user_id_sender | user_id_recipient | message_text | read_flag | sender_delete_flag | recipient_delete_flag | timestamp

Поверх этой структуры наворачиваешь логику за пару часов максимум

У меня на прошлой работе тим-лид был такой.

Может потому он и был тим-лидом, что использовал простые и рабочие решения, а не громоздкие сильносвязанные конструкции?

можно добавить еще reply_to и получить простейшее дерево, ссылающееся на само себя

Если так, то что делал с рассылками «от администрации»?

«От кого» == 0 В логике отмечаешь, что такое сообщение получают все пользователи

Как помечал флаг «прочитано»?

Вариантов - вагон :)

Т.е. при рассылке письма дублируются для каждого получателя?

Может потому он и был тим-лидом, что использовал простые и рабочие решения, а не громоздкие сильносвязанные конструкции?

Нет не поэтому. А потому что написав серверную сторону, он меня спрашивал: «Какого хрена у тебя Web-интерфейс еще не готов?».

Нет конечно :) Ты даже не в состоянии понять структуру БД? Ох, зря ты на тимлида гонишь, ох зря...

id | user_id_sender | user_id_recipient | message_text | read_flag | sender_delete_flag | recipient_delete_flag | timestamp

Эта структура хороша для персональной переписки, хотя есть нюансы.

Например, поле sender_delete_flag - зачем оно? Почему бы не удалить запись физически, коль сам начинатель ее решил удалить?

Если так, то что делал с рассылками «от администрации»?

«От кого» == 0 В логике отмечаешь, что такое сообщение получают все пользователи

Все пользователи, которые поставили у себя галку «Получать сообщения администрации». Таким образом, нужна еще таблица, в которой хранятся настройки пользователей, типа

user_id | admin_send_subscribe | email | send_to_email

Да, email нужен чтоб получать сообщения на почту. send_to_email - флаг, отправлять ли сообщения на почту.

Как помечал флаг «прочитано»?

Вариантов - вагон :)

Да, вагон. Навскидку: заводить еще одну таблицу вида:

user_id | read_message_id

Как пользователь прочитал сообщение, id этого сообщения попадает в данную таблицу. При дальнейшей работе смотреть, прочитано ли оно пользователем или нет. Недостатки: неограниченный быстрый рост таблицы, грубо говоря, одна мессага от администрации порождает количество записей, равных количеству пользователей, если все прочтут.

Прикинем: предполагается как минимум одна мессага в день от администрации (робот пишет отчет всем пользователям). Возьмем 5000 пользователей, умножим на 365 дней, получим ~2 млн. записей в год. Пусть id занимают 4 байта, одна запись в таблице будет 8 байт. Итого таблица эта займет 16 МБайт за год работы не учитывая индексы. Впринципе по объему немного, но вот количество записей (2 млн.) настораживает для такой задачи.

Почему бы не удалить запись физически, коль сам начинатель ее решил удалить?

Потому что операция DELETE очень тяжелая

Все пользователи, которые поставили у себя галку «Получать сообщения администрации». Таким образом, нужна еще таблица, в которой хранятся настройки пользователей

Не нужна. Этот флаг можно хранить в таблице с пользовательскими данными, вместе с логином и паролем, например

Да, email нужен чтоб получать сообщения на почту. send_to_email - флаг, отправлять ли сообщения на почту.

Не нужно. ОТправляйте email сразу или заводите отдельную очередь. Не обязательно на SQL

Навскидку: заводить еще одну таблицу вида:

Не нужно, в моей таблице есть флаг read_flag, который ставится при прочтении сообщения адресатом. Такой флаг для отправителя не имеет смысла

Нет конечно :) Ты даже не в состоянии понять структуру БД?

и Какие нынче существуют готовые OpenSource системы уведомлений (нотификация) или переписки на сайте? (комментарий)

и тут Какие нынче существуют готовые OpenSource системы уведомлений (нотификация) или переписки на сайте? (комментарий)

пока наблюдаю у вашего велосипеда такие же квадратные колёса :)

Да на здоровье :)) Мне ничуть не хочется уговаривать тебя использовать те или иные паттерны. Я подобных систем написал уже достаточное количество и руководствуюсь исключительно опытом.

Почему бы не удалить запись физически

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

faye + 4-5 часов работы

faye + 4-5 часов работы

for Node.js and Ruby

В метках же написано - PHP.

Вот реалтайм-чатик - там да, есть где развернуться :)

Единственной сложностью там будет придумать организацию БД и выбрать ее тип. А так - websockets - и все дела!

sender_delete_flag | recipient_delete_flag

А есть ли смысл хранить удаленные сообщения, как это делается на ЛОРе?

ну и что? отправлять сообщению в канал можно тупо отправив post запрос на сервер faye.

Вы глубоко заблуждаетесь :) Но это тема для отдельной беседы

Я уже писал, что DELETE - очень тяжелая операция, без особой нужды ее лучше избегать