在单独的数据库表中的人名结构

我想知道何时何时将数据结构拉入单独的数据库表中，当它出现在几个表中。在单独的数据库表中的人名结构

我已经将12个属性地址结构拉到一个单独的表中，因为我有几个不同的实体包含这种格式的单个地址。

但是我的3个属性人名结构（给定，中间，姓氏）呢？

是否应该将它放入它自己的表中，并用包含名称的所有实体的外键引用......例如，公司桌上有联系人姓名，公民桌上有人名等

这些最好留在主表中作为属性还是应该提取？

来源

2009-07-22 lox

请注意，我在说的是这些数据结构只能作为整体的一部分存在，而没有其他表可以指向同一个实例。 – lox 2009-07-23 07:34:16

我通常会在Person表上保留地址，除非在每个实体上有绝对统一的地址，或者实体可能有任意数量的地址，或者地址需要在实体之间共享，或者如果这是一个大型企业产品，我知道我必须投资全地方的基础设施，否则我最终会把所有的东西都拆掉。

把你的地址放在一个单独的表格中很有意思，因为它很灵活，但是在一个小项目缺乏像上面提到的那样的特殊需求的情况下，这可能是一个小小的浪费。始终注意复杂性和灵活性之间的平衡。灵活性非常重要，但要区别对待......很容易在这里投资太多！

具体而言，我尝试过（例如）地址之类的一对一关系的时代，我最终将它们重构为表格，因为它引入了一堆令人头痛的问题，包括更复杂的查询，处理地址不存在的情况等等。更多的实体也增加了你的认知负荷 - 这使得项目难以思考。就我而言，这是一笔不必要的成本，因为没有具体的需要，事实上，甚至不具有灵活性。因此，根据我的经验，我会“尝试”将地址保存在同一个表中，并且我一定会保留这些地址的名称 - 除非有特殊需要。

所以为了解释爱因斯坦，让它尽可能简单并且不简单。但在短期内，实验。这是学习这些课程的最佳方式。

来源

2009-07-22 13:30:49

这是关于不重复的信息，所以你不想在两个地方存储相同的信息。

另一个有用的经验法则是每个表格一个实体。如果你发现一个表包含“人”和“秩序”，那么你可能应该把它们分成两个表。你可能会发现查看一些数据库设计的基础知识很有帮助，在这里有很多关于stackoverflow的相关问题。

开始与这些...

What is normalisation?

What is important to keep in mind when designing a database

How many fields is 'too many'?

More tables or more columns?

来源

2009-07-22 13:12:52

但是，由于新的PersonName表行被指向外键，PersonName信息不会因为删除公司行或公民行而消失。然而，它的存在只有通过这些指点行的存在才是合理的。 – lox 2009-07-22 13:55:34

为PersonNames打出一张单独的表是浪费的。 ;）但是如果你这样做了，你可以使用Cascade Delete，这样当Person被删除时，数据库将删除相应的PersonName。在SQL Server中，这是关系中的一个选项。 – 2009-07-22 14:05:12

现在，如果PersonName被几个不同的东西使用 - 比如说PersonNameID 5是Brian MacKay，并且它出现在PersonID 200和CitizenID 120中，那么您不能再删除PersonID 200，因为Cascade会失败。所以：要么把人和公民结合成一张桌子，要么不把名字结构打破成一张桌子，或者两者兼而有之，简化你的生活。我建议做两个。 – 2009-07-22 14:08:35

提取它们。你的目标应该是在你的数据库中没有重复的数据。阅读Normalization

来源

2009-07-22 13:14:14 DanDan

你知道，像名字/姓氏一样，它不一定重复数据，而是重复数据结构。对我来说，重复这些结构是可以的，只要你不重复数据。在简单性方面的折衷是值得的。 – 2009-07-22 14:01:27

创建整个数据模型的人实体会给你这个现在和未来的优势 - 如发生接触，或在不同背景下个体

同一个人。节省冗余。
信息可以保持并保持最新状态。
更容易搜索一个人，并找出他们 - 即它是否是相同的约翰史密斯？
您可以扩展信息 - 即为此人更方便地维护地址。
编程将更加一致，调试也将变得更加容易。
让您更接近'自我记录'系统。

来源

2009-07-22 13:20:46 blispr

这实际上取决于你正试图解决的问题。一般来说，拥有某种“人物”表格可能是一个好主意，它保存着人们的细节。但是，在某些情况下，这可能是一个非常糟糕的主意。

例如，如果您持有由医生向人们写出的处方的详细信息。在一些国家，这是一个法律要求，规定的详细信息是与他们的名字，而不是他们目前的名字。例如，一名妇女可能被开处方为X小姐，但她随后结婚并成为Y夫人。如果您有一张与处方表相关的人桌，您现在将会看到错误的细节，并可能面临法律后果。在这种情况下，您可能需要将该人员的相关详细信息复制到处方表中，即使这可能会复制数据。

所以再次 - 这取决于你正试图解决的问题。不要盲目追随人们认为的最佳实践。了解您的数据及其相关问题，然后尝试遵循适合的最佳做法。

来源

2009-07-22 13:30:12

作为与其他（完全有效）答复的对应点：在您的应用程序的当前结构中，对于给定的个人（不只是名称，实际“人员” - 多个人可能是“John Smith “）出现在多个表中？这种情况发生的可能性越小，从正常化中获益的可能性就越小。

另一种想法是实体。在标签（名称）之外，它们是否在“客户”实体和“员工”实体之间有重叠？

来源

2009-07-22 13:30:59

取决于您使用的数据库。

如果你想在你的表上进行快速查询，你应该对你的表进行反规范化处理。必须运行多个JOIN将需要更长的时间，并且使查询更加复杂。另一方面，如果你的目标是要有一个灵活的存储数据库，并不意味着大量的快速响应查询，那么通过将这些表分割成多个xref表格来规范化表格将提供设计更灵活，并减少提交重复数据的需求。

由于解除归一化为“优化”，因此我建议您先对表格进行归一化处理，正确编制索引并查看是否在查询中遇到任何瓶颈。如果是这样，在需要的地方平整受影响的表格。

来源

2009-07-22 13:44:07 ascotan