Как создать структуру таблицы?

Question

[Максим]

БД MySQL

Хочу сделать уведомления для пользователей.

Простейший вид таблицы такой:

id | текст сообщения | сериализованный массив с id пользвателей


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

Какие-то сообщения могут показываться двум пользователям, какие-то 2 тысячам

Ну и перебирать мне так строки все и в массивах искать айди думаю очень скоро станет медленно.

Так вот прошу помощи кто чем может) Как спроектировать подобное?

Answer 1

[Melkij]

Делаете таблицу прочитанных сообщений со структурой user_id & id_уведомления, PK на оба поля.
Показ уведомлений:

select текст from уведомления left join прочитанные_уведомления on id_уведомления=id and user_id=? where user_id is null

И метите уведомления прочитанными созданием таковых записей.

Или можно инвертировать логику — вносить в таблицу id непрочитанных уведомлений и удалять при прочтении.

Comments

[Максим]

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

[Алексей Сундуков]

>скажем миллион записей будет
Миллион это совсем не много. Делайте как Melkij советует, это правильное решение. Касательно подхода не так принципиально, адейтить поле или удалять запись. Это спички.

[Melkij]

Здесь один единственный PK на таблице, данных лишних вообще нет — такая работать будет быстро на весьма внушительных объёмах. 1 лям — это вообще ни о чём.
Потом запросто партицируется по user_id.

По спичкам:
добавлять столбец не нужно, зачем? Придётся индекс раздувать или иначе — вообще данные с диска поднимать, вместо работы только по PK. Совершенно бесполезные манипуляции.

Хранить же прочитанные или только непрочитанные — зависит от пользователей, какая их часть активно читает уведомления. Обычно активных пользователей меньше и тупо компактнее хранить прочитанные.

Answer 2

[patashnik]

messages:
+----+------+
| id | text |
+----+------+

user_messages:
+---------+------------+
| user_id | message_id |
+---------+------------+

Answer 3

[nokimaro]

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

Answer 4

[Vampiro]

можно не заморачиваться и сделать
user_id, message
А зачем вам возиться с id сообщений? Пользователь либо прочитал все уведомления, и ткнул кнопку «прочитано» (тогда очищаем message), либо не прочитал ничего. Кто-то выборочно читает уведомления и тискает на кнопки?

Но если вам очень хочется правильно + адимнку сообщений и прочие заморочки, то да, придется делать еще одну табличку.

Answer 5

[neyronius]

Используйте таблицу связей уведомлений и пользователей — на лицо отношение многие ко многим. После показа удаляйте связь.