类似于 Facebook 的通知系统的数据库架构

Question

我正在尝试设计一个类似于 Facebook 的通知系统，但我已经遇到了一些困难。我的要求是能够支持无限数量的通知类型，这些通知类型可能需要呈现不同类型的元数据。

我想我将设计如下架构：

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

**NotificationType**
Id
Name
Description

我真的想尽量避免在数据库中存储 HTML 字符串，但是，我也不是特别喜欢存储 blob。

我可以查找NotificationType表并引用另一个存储特定于该类型的数据的表，但是，这意味着每次我创建一个新的notificationtype时我都需要创建一个新表。我相信我也会让自己陷入一个必须编写动态 SQL 来获取数据的世界。

有人对我有什么建议吗？

Answer 1

这就是我最终解决这个问题的方法。

我决定使用字典来存储每种通知类型唯一的数据。然后，我将该字典对象序列化为二进制字符串，并将其与每个通知一起存储在数据库中。我有一个分配给每个通知类型的模板，其中包含占位符，即。我可以快速用字典对象中的值替换“{song-title}”。

Answer 2

通知系统数据库设计：

1. 通知表：

   • id（主键）
   • notification_object_id（引用 notification_objects 表的外键）
   • receiver_id（引用用户表的外键）
   • 状态（通知状态，例如已读、未读……）

2. Notification_objects 表：

   • id（主键）
   • entity_type_id（引用entity_types表的外键）
   • entity_id（相关实体的ID，可以是post_id、user_id或comment_id）
   • status（通知对象的状态）

3. Notification_changes 表：

   • notification_object_id（引用 notification_objects 表的外键）
   • actor_id（引用用户表的外键）
   • 状态（变更状态）

4. Entity_types 表：

   • id（主键）
   • entity_table（实体表的名称，例如帖子、用户、评论）
   • notification_type（通知类型，例如，创建新帖子、帖子的新评论……）
   • 描述（通知类型的描述）

使用此结构，您可以在notifications表中存储有关通知接收者的信息，在notification_objects表中存储有关通知对象的信息，以及在notification_changes表中存储有关触发通知的参与者的信息。这些表将通过外键连接来管理它们之间的关系。