Как де-нормализовать базу данных mysql для уведомлений пользователей?


Я думаю, что необходимо де-нормализовать базу данных для уведомлений пользователей. Например, при помечении поста (который должен быть рассмотрен пользователем) мы добавляем столбец flag ENUM('yes', 'no') (или столбец состояния). Найти помеченные события для пользователя можно путем подсчета с помощью предложения WHERE из user_id='XX' AND flag='yes'.

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

Я думаю, что де-нормализация может помочь добавить столбцы уведомлений в пользовательскую таблицу как

post_flags tinyint(3),
comment_flags tinyint(3),
photo_flags tinyint(3),

В этом случае нам нужно выполнить дополнительный запрос на запись для обновления столбцов флага пользователя на каждом соответствующем действии. Например, при помечении поста: UPDATE users SET post_flags=post_flags+1 WHERE user_id='XX'. Я забочусь о том, чтобы обеспечить выполнение последнего запроса, чтобы избежать любого несоответствия между этим число и количество помеченных столбов; но я думаю, что это может быть обеспечено TRANSACTION.

Таким образом, мы получаем все уведомления с одним запросом для часто посещаемых страниц профиля.

На правильном ли я пути? или для этой цели распространен другой хитрый подход?

3 3

3 ответа:

Вам, вероятно, будет лучше с таблицей уведомлений пользователей.

create table user_notifications (
  user_id integer primary key, -- ? references users, not shown
  post_flags unsigned tinyint(3) not null default 0,
  comment_flags unsigned tinyint(3) not null default 0,
  photo_flags unsigned tinyint(3) not null default 0
);
Отдельная, более узкая таблица является одновременно логичной и (вероятно) более быстрой. Unsigned для флагов, потому что отрицательные числа там не имеют смысла,и MySQL не применяет ограничения проверки.

Что касается нормализации, user_notifications находится в 5NF.

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

Я не думаю, что это очень эффективно. Может быть, это полезно, когда вам нужно найти также комбинации флагов, например post_flags или comment_flags или photo_flags, и порядок запроса также важен.