Схема базы данных для системы уведомлений Подобно Facebooks

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

Я думаю, что я разработаю схему следующим образом:

**Notification**
Id (int)
TypeId (int)
RecipientId (int)
SenderId (int)
SendDateTime (DateTime)
Read (bool)
MessageData (...Blob?)
Deleted (bool)

**NotificationType**
Id
Name
Description

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

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

Есть ли у кого-нибудь предложения для меня?

Ответ 1

Вот как я решил решить эту проблему.

Я решил использовать словарь для хранения данных, уникальных для каждого типа уведомлений. Затем я сериализую этот объект словаря в двоичную строку и сохраняю его в базе данных вместе с каждым уведомлением. У меня есть шаблон, назначенный каждому типу уведомлений, который содержит держатели мест, т.е. '{song-title}', который я могу быстро заменить значениями из моего словарного объекта.

Ответ 2

Я ищу похожую вещь, но у меня есть проблема, чтобы понять ваши сущности.