Sql Db设计-表依赖关系和命名约定

我正要为一个新项目设计一个数据库，我被一些概念性的东西卡住了

我最初的问题和这个很相似。

即: 如果我有一个表用户，然后我得到的产品，只有用户 将具有，该表应命名为用户产品还是仅命名为产品？ 这是一对多的关系

在上面的帖子中，我发现PerformanceDBA的答案非常有用，而且写得很好， 但有几点我不确定。引用部分答案：

用户：：产品是否为1：：n并不重要。重要的是产品是否是一个独立的实体，它是否是独立的，也就是说，它可以独立存在。因此是产品，而不是用户的产品。如果产品仅存在于用户的上下文中，即它是依赖的， 然后是用户的产品

这是一个非常有趣的观点，但产生了另一个问题： 独立表和从属表的定义是什么

例1，我们有两个表：

表用户

Id
Username
FullName

Id
Username
FullName

1:：n表消息，表示用户发送的消息集合

UserId (FK to User.Id)
Text

消息表是否依赖于用户表？ 我在这里问自己的问题是：如果没有用户，消息实体会存在吗？但我不确定答案是什么，因为信息可能存在，但可能是匿名的。这是否足以使消息表依赖于用户表，因此我应该将该表命名为UserMessage

例2，我们有两个表：

表用户

Id
Username
FullName

Id
Username
FullName

1:：1表配置文件，表示用户配置文件

UserId (FK to User.Id)
First Name
Last Name
Gender

同样的问题，表配置文件是否依赖于用户表？我认为是的，因为没有用户的个人资料是没有意义的

---

<>我不确定，那么我如何才能安全地决定一个表是否依赖另一个表？

我想你可能真的有3个实体要考虑。用户、产品和用户\产品。通过用动词描述关系来测试它们。用户和产品之间的关系很可能是多对多的关系。用户可以订购多个产品，而产品可以由多个用户订购。这表明它们之间需要一个包含两个表的主键的复合表，并且可能只有当属性描述了关于用户/产品组合的事实时才需要属性。用户产品是将用户与他的产品以及产品与订购者联系在一起的东西，因此是依赖的

也就是说，在您的示例中，消息和概要文件表是相互依赖的，因为如果没有用户主键，它们就无法存在。使用user-user\u消息和user-user\u配置文件

独立表的另一个示例是查找表代码/描述表

---

要回答您的最后一个问题，如果一个实体的主键必须存在于另一个实体中才能存在，则该实体被视为是依赖的，即没有用户，您就无法拥有一个配置文件，因此它是依赖的。

我同意您的第二个示例用户配置文件，但我仍然不确定第一个用户消息。假设一个用户写了一条消息，那么他的id和消息文本被写在消息表中；然后用户删除他的帐户。消息仍将存在，但不会被任何用户消息删除。UserId将为NULL。在这种情况下，表消息仍然依赖于表用户吗？如果用户被删除，他的消息也应该被级联删除。这应该由数据库约束强制执行。否则，您将面临没有用户的孤立行消息的风险。如果需要为已删除的用户保留邮件，则不应删除用户，而应使用标志或其他标记将其标记为非活动，或将用户和邮件数据移动到存档表中。归根结底，表是否依赖取决于所建模数据的要求和规则。好吧，那么，如果我想存储消息，即使用户被删除了，该怎么办？比如说，出于统计目的，或者我想显示匿名发送的消息？在这种情况下，我会将costraint设置为ON DELETE set NULL。这会使消息表独立吗？那么依赖性基本上取决于costraint设置？是否删除级联=依赖？