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

Question

Я думаю, что необходимо де-нормализовать базу данных для пользовательских уведомлений.Например, при пометке поста (который должен учитывать пользователь) мы добавляем столбец 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.

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

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

Answer 1

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

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
);

Отдельная, более узкая таблица логична и (вероятно) быстрее. Без знака для флагов, потому что отрицательные числа не имеют смысла, а MySQL не применяет ограничения CHECK.

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

Answer 2

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

Answer 3

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