Database 什么时候应该将属性放入单独的表中？

什么时候应该将属性放入单独的表中？我的意思是我有一个属性，但我是否应该把它和一个表person的其他属性放在一起，还是应该把它放在一个单独的表中，person_ID作为FK

---

第二，什么时候形成关联类？它能在类和它的多元属性之间形成吗？Ex-class book具有属性author。一个作者可以写很多书，一本书可以由很多作者写

当你期望一个人可以有多个属性时，你应该在一个单独的表中放置一个属性。否则，没有太多的理由将其分开，这样做可能会有一些概念上的开销。（如果每个属性都不必要地位于自己的表中，那么当您必须编写一个查询来检索一个人的五个不同属性时，这可能会非常烦人。）

---

只要两个表之间的关系是多对多的，就应该在它们之间创建一个关联表。您的作者-书籍示例是一个很好的示例。

这取决于该属性依赖于什么。如果它是您正在创建的实体（person）的一个属性，那么它应该放在同一个表中，但正如您在一本书中所说的，一本书可以有许多作者，一位作者可以写很多书，您必须考虑实体和属性之间的关系。是一对一关系，一对多关系还是多对一关系，等等

这就是说，如果你的人只能有一个属性值，并且只有一个人可以有该属性，那么它应该放在同一个表中

在以下情况下，您应该有一个关联表：

一个人一次可以住在不止一所房子里（家和度假屋），但更多的人也可以住在这些房子里

显然，在上面的例子中，我们忽略了一个事实，即一个人一次不能在多个地方

作为一般规则，属性应取决于“键、整个键和除键以外的任何内容”

更新@ruakh所说的内容：

---

如果您分离属性，它可能会产生开销，但您可以使用一个工具来适应这种开销，即创建表的视图。我不确定您使用的是什么数据库系统，但MySQL具有此功能。视图是可以使用SQL查询在当前数据库上创建的“虚拟”表。您可以组合多个表，并像查询普通表一样查询该视图。

所以在类书和它的多变量属性author之间有关联类可以吗？类书{authors[1…*]}还有一件事..在进行书籍和作者的OMT设计时，我应该显示这个M:N关联吗？或者我应该像以前在一本类书中那样展示…？@LogicianUnix:等等，你是在问你的程序——你的OO模型——是否应该有一个与数据库的关联表相对应的关联类？如果是，那么：可能不是。你的

作者

类应该有一个

书籍

参考文献的列表，反之亦然。然而，您可能想要一个

AuthorBook

类的一个原因是，除了“此作者是本书的作者之一”之外，该关系是否还有其他属性。（例如，

AuthorBook

如果您希望元数据指示哪个章节和哪个版本，那么它可能很有用。）我如何在UML中表示图书作者关系？我应该用关联类画一个M:N关联吗？或者我应该在类图中显示为书{authors[1…*]}吗？这取决于您的需求，我相信它们都是概念的有效表示。如果需要制作实体关系图，则这取决于创建图时要使用的样式（鱼尾纹或chen模型）。