php - 如何设计引用多个表的灵活 MySQL 通知架构？

Question

我决定在另一篇 StackOverflow 帖子的启发下开发一个通知系统，该帖子建议我将通知与通知正文分开。因此，我有以下架构:

notifications
id | user_id | notification_object_id | is_read

notification_objects
id | message | type

我以这种方式设置它，这样我就可以创建一个通知对象并将其发送给多个用户，以防通知对象适用于多个人。类型用于按类型将消息压缩到一个通知中，有点像 Facebook 所说的“John Doe、John Smith 和其他 27 位用户评论...”，而不是给你 29 个单独的通知。

(表和列的命名模式是针对 CakePHP 3 的“包含”)

我需要帮助的是如何绑定(bind)将在请求中发挥作用的不同用户或对象。用户可能已发表评论，因此我可能需要发消息的用户的 user_id 并将其存储在某处。

除用户外还有其他情况；一个人可能想知道评论的 ID，这样他就可以点击通知并直接转到 comment/81。我有很多用例，我想存储不同类型的 id，这些 id 是其他表(用户、评论、文章等)的外键，其中一些可能需要两个外键(比如你想提到“Chris 有评论了你的 article '如何向 StackOverflow 寻求帮助'”)，并在通知中链接了 Chris 的 user_id 和文章的文章 ID。

每种不同类型的通知可能有不同的值和需要从中提取信息的表格。从哪里开始创建此模式比较好？

Answer 1

我将尝试从面向对象的角度回答这个问题。在类而不是表中说话时，您可能会从具有基本属性(日期、时间、可能是一条消息)和几个专门化类，如具有附加属性(评论、评论用户)的 NewCommentNotificationObject 或 NewFriendNotificationObject。深入到数据库架构，然后您可以应用一种典型的 ORM 模式。

具体的表继承(只是为了完整性)

使用 concrete table inhericance 可能不是一个好主意，因为它会归结为每个通知类型的单独表(即 comment_notification_objects 表，也许还有更多)。这不会很好地扩展，并且您将无法使用外键从 notification 表中引用它们。此外，您将无法通过单个查询选择一组不同类型的通知(没有 UNION 之类的东西)。

单表继承

Single table inheritance 将仅使用带有类型鉴别器列的单个表。这个单一的表(我们称它为 notification_objects)需要包含一个 type 列来描述记录实际上是什么类型的通知(你实际上已经在你的模式中了) ).您还需要用于特殊通知类型可能具有的所有属性的列(例如，user_id 和 comment_id 列)。

   +--------------+
   | notification |
   +--------------+
   | id           |
+--| object_id    |
|  +--------------+
|
|  +-----------------------+
|  | notification_objects  |
|  +-----------------------+
+->| id PK                 |
   | date                  |
   | type                  |
   | user_id FK            |--...
   | comment_id FK         |--...
   | friend_id FK          |--...
   | [more fields to come] |
   +-----------------------+

优点:

1. 使用单个查询加载所有通知
2. 使用外键保持参照完整性

缺点:

1. 扩展性差(您需要为每种通知类型添加新列)
2. 表将被稀疏填充(许多列将为 NULL)

当您有一组不定期更改的中等大小的通知类型时，我会推荐此架构。

类表继承

Class table inheritance 介于两者之间；在这里，您将创建一个中央 notification_objects 表，并为每种通知类型创建单独的表(例如，带有 id 列的附加 comment_notification_object 表(在turn 是 notification_object 表以及 user_id 和 column_id 的外键:

   +--------------+
   | notification |
   +--------------+
   | id           |
+--| object_id    |
|  +--------------+
|
|  +----------------------+      +------------------------------+
|  | notification_objects |      | comment_notification_objects |
|  +----------------------+      +------------------------------+
+->| id PK                |<--+--| id PK/FK                     |
   | date                 |   |  | comment_id FK                |--...
   | type                 |   |  | user_id FK                   |--...
   +----------------------+   |  +------------------------------+
                              |
                              |  +--------------------------------+
                              |  | newfriend_notification_objects |
                              |  +--------------------------------+
                              +--| id PK/FK                       |
                                 | friend_id FK                   |--...
                                 +--------------------------------+

                                 [more TABLES to come...]

类表继承还允许您使用单个选择查询来查询所有通知。根据您需要的数据量，您需要将 JOIN 添加到相应的专用表。

优点:

1. 在不修改现有结构的情况下很好地扩展/添加新类型
2. 使用外键保持参照完整性

缺点:

1. 当您需要的不仅仅是最少的字段集时，您将需要 JOIN 专用表(可能会影响性能)

当您有很多不同的通知类型或经常扩展您的对象模型并且需要定期更改/添加新的通知类型时，我会推荐此架构。

关系框之外

您的问题明确询问了关系模式，因此我专注于此。跳出这个框框思考时，替代解决方案可能包括:

• 无模式 NoSQL 数据库
• 遵循发布/订阅架构的消息系统