确定数据库关系答案

【问题标题】：Determining database relationships确定数据库关系
【发布时间】：2018-09-13 22:35:12
【问题描述】：

我正在向应用程序添加一项功能，用户可以在该应用程序中向其他用户发送和接收私人聊天消息。（一条消息只能发送给一个用户）。

用户模型很简单，有id、name等。消息模型有id、title、body、senderId和receipientId。

一个用户可以发送很多消息，也可以接收很多消息，所以我认为这是一个多对多的关系。但是，一个用户可以发送多条消息，但每条消息将由一个用户发送，因此可以是一对多的。

我如何确定这是一种什么样的关系。我在网上搜索了有关关系的信息，但无法弄清楚这一点。我正在使用实体框架。

我了解基本的数据库关系，但这一个很棘手，因为它既是发送者又是接收者。

【问题讨论】：

嗨。请说出您正在遵循的信息建模和数据库设计教科书并将您所做的事情与它联系起来。否则，答案只会重写教科书。记录设计的产品手册不是关于如何设计的教科书。 PS 您似乎对“发送者 S 向接收者 R 发送消息”或“消息 M 是发送者 R 向接收者 R 发送文本 T”之类的关系/关联感兴趣。首先找到实体，然后找到它们上的关系（船舶）/关联。关系（船）/关联可以给出“关联实体”。然后根据你所遵循的方法观察基数。
@philipxy，我很欣赏这个链接，但这对我一点帮助都没有。我了解基本的关系商店，但我的问题（我说得很清楚）有点不同。一对多关系链接回相同的用户表，因此有点不同。我想澄清这种关系，但在我自己搜索后无法找到。
您需要提供您的参考以及您如何遵循它。消息是弱实体吗？那么你想要基数的关系是什么？是关系吗？在哪些实体上？哪个是“这个”关系？不同的方法以不同的方式使用“关系”——关联与 FK。您是在向用户谈论 FK 吗？不清楚你想知道什么。如果你知道你有 FK，你还需要知道什么？不同的方法以不同的方式确定和记录基数。根据我的第一条评论采取行动。请参阅点击谷歌搜索“stackexchange 作业”。 PS 将说明编辑到帖子中，而不是 cmets。
我还不清楚我描述了我的两个模型，它真的没有那么复杂。这两张海报已经帮助了我，也许可以做一些笔记。再一次，您的 cmets 无济于事。
两个答案都以您不清楚。答案的其余内容验证了我的 cmets。接受的关于 2 个 FK 的答案可能会对您有所帮助，但它肯定不能回答您的问题，因为您知道有 2 个 FK 但您正在谈论其他一些事情，“这种关系”。第一个答案在 FK 的意义上提供了“关系”，而在其他关联的意义上提供了“关系”。他们不知道你想要什么并且在猜测。所以我支持我的cmets。

标签： sql sql-server database entity-framework relational-database

【解决方案1】：

我想知道我是否没有完全理解，因为您似乎已经回答了自己的问题？可能会出现一些混淆，因为您在“发送者”和“接收者”旁边使用术语“用户”。

发件人和收件人都是用户，由 UserID 标识，但收件人与发件人有一些不同的行为。它应该被视为模型中的不同元素。

发件人与消息具有一对多的关系，因此消息知道它的发件人是谁。

但是，消息与其收件人之间存在一对多的关系 - 因此在典型的设计模式中，消息不知道其收件人是谁，而是所有收件人都知道他们的消息是谁。因此，通常需要某种具有 messageID 和接收者（通过 UserID）的 messageRecipients 映射实体。

User                         Message                      MessageReceiver
--------------------         --------------------         --------------------
UserID                       MessageID                    MessageReceiverID 
UserName                     Sender (FK UserID)           Message (FK MessageID)
.                            MessageBody                  Recipient (FK UserID)
. (other fields)             .                            .
.                            . (other fields)             . (other fields)
                             .                            .

当我们想象我们的消息实体与典型的电子邮件或即时消息编辑器具有相同的字段时，谈论单独的“消息接收者”实体可能看起来很奇怪——这些总是有一个列出收件人的地方。但这就是问题所在。如果我们的数据字段是我们需要单独处理这些项目的项目列表，那么我们可能需要一个新实体来管理它们。

无论如何，这就是我的看法。希望对您有所帮助。

【讨论】：

谢谢，没见过这样的设置。我正在学习的一个问题是，我参加的每门课程似乎都以不同的方式做事。我只是假设每条消息都有一个发件人用户和收件人用户的 ID。但是我再次困惑如何看待这个，如果我说“用户发送很多消息并接收很多消息”可能是多对多，但看起来它确实是两个一对多的关系..？跨度>
我绝对认为这是一对一对多的关系。这可能不是解决问题的唯一方法。例如，如果我是用户并且我打开了两个聊天窗口——一个是与 albert、betty 和 chris 的群组对话。但第二个窗口就在我和克里斯之间。我不希望他只发送给我的消息出现在群聊窗口中。上述解决方案不支持这种区别。那么，现在我们是否需要某种“聊天室”ID。一个有效的应用程序，一个不同的模型
附带说明，您的消息实体可能也应该有一个时间戳。

【解决方案2】：

假设我理解正确：

Message 与 senderId 上的 user 具有多对一关系。 Message 还与 recipientId 上的 user 具有多对一关系。

查询数据类似于：

SELECT
    s.Name AS Sender
    ,r.Name AS Recipient
    ,m.Title
    ,m.Body
FROM
    Message AS m
INNER JOIN User AS s ON
    m.SenderID = s.ID
INNER JOIN User AS r ON
    m.RecipientID = r.ID

Quick and dirty ERD

【讨论】：

谢谢，所以这不是多对多的关系吗？或者它是并且它被分解成两个单独的一对多的？我不知道为什么我只是认为“用户发送很多消息并接收很多消息”所以它必须是多对多。
添加了一个基本的 ERD 以帮助显示正在发生的事情。这是两个一对多的关系，但有点不稳定，因为用户表有两个用途。这假设所有发件人都可以是收件人，反之亦然，根据您给定的用例，这似乎是正确的。
谢谢！这对我理解有很大帮助，比我想象的要容易得多。