Question

我即将为一个新项目设计一个数据库，而且我有点坚持一些＆＃34;概念＆＃34;东西。

我最初的问题与此问题非常相似。 Relational table naming convention

那是：＆＃34;如果我有桌子＆＃34;用户＆＃34;然后我得到的产品只有用户如果表格被命名为＃34; user-product＆＃34;或只是＆＃34;产品＆＃34;？这是一对多关系。＆＃34;

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

＆＃34;如果user :: product是1 :: n并不重要。重要的是产品是否是一个独立的实体，是否是独立的，即。它可以独立存在。因此产品，而不是user_product。如果产品仅存在于用户的上下文中，即。它是依赖的，然后是user_product。＆＃34;

这是一个非常有趣的观点，但会产生另一个问题：独立和依赖表的定义究竟是什么？

示例1 ，我们有两个表：

表User

Id
Username
FullName

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

UserId (FK to User.Id)
Text

Message表是否依赖于User表？我在这里问自己的问题是：＆＃34;消息实体是否会在没有用户的情况下存在？＆＃34;但是我不确定答案，因为它会是＃34;信息会存在，但会是匿名的。＆＃34;这足以使Message表依赖于User表（因此我应该将表命名为＃34; UserMessage＆＃34;）？

示例2 ，我们有两个表：

表User

Id
Username
FullName

1 :: 1表格个人资料，代表用户个人资料

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

同样的问题，表格是否依赖于User表？我认为是这样，因为没有用户的个人资料不会有意义。

我不确定，所以我怎样能安全地决定一张桌子是否依赖另一张桌子？

Answer 1

我认为你可能真的需要考虑3个实体。用户，产品和user_product。通过用动词描述它们来测试关系。用户和产品之间的关系很可能是多对多的（用户可以订购许多产品，并且许多用户可以订购产品）。这表明需要在它们之间使用两个表的主键的复合表（并且仅当它们描述关于用户/产品组合的事实时才可能是属性）。 user_product是用户与他的产品（以及订购产品的产品）的链接，因此是依赖的。

也就是说，在您的示例中，消息和配置文件表是相互依赖的，因为没有用户（他们的主键）它们就不存在。使用user - user_message和user - user_profile。

独立表的另一个例子是查找表（代码/描述表）。

要回答你的上一个问题，如果一个实体的主键在它存在之前必须存在于另一个实体中，则该实体被认为是依赖的，即你没有用户的配置文件，因此它是依赖的。

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

1 个答案: