我想知道何时何时不将数据结构拉入单独的数据库表中，当它出现在几个表中时。
我已将12属性地址结构拉到一个单独的表中，因为我有几个不同的实体包含这种格式的单个地址。
但我的3个属性人名结构（给定，中间，姓）怎么样？
这是否应该放入自己的表中，该表用外键引用包含名称的所有实体...例如公司表有联系人姓名，公民表有人名等。
这些最好留在主表中作为属性还是应该被提取出来？
答案 0 :(得分：1)
这不是重复信息，因此您不希望在两个地方存储相同的信息。
另一个有用的经验法则是每个表一个实体。如果您发现一个表包含“人”和“订单”，那么您可能应该将它们分成两个表。
并且（让自己面临重复信息的风险......）您可能会发现查看一些数据库设计基础很有帮助，这里有很多关于stackoverflow的相关问题。
从这些开始......
What is important to keep in mind when designing a database
答案 1 :(得分：1)
在整个数据模型中创建人员实体将为您提供当前和未来的优势 -
答案 2 :(得分：1)
我通常会将地址保留在Person表中，除非每个实体都需要绝对统一的地址，或者实体可以有任意数量的地址，或者地址需要在实体之间共享，或者如果它是一个大型的企业产品，我知道我必须在整个地方投资基础设施，否则我最终会把所有东西都扯掉。
将您的地址放在一个单独的表中是有趣的，因为它很灵活，但在一个缺乏特殊需求的小项目的环境中，如上所述，这可能是一个轻微的浪费。始终注意复杂性和灵活性之间的平衡。灵活性很重要，但要有区别......在那里投资的方式太容易了！
具体而言，我尝试（例如）地址之类的一对一关系的时间，我最终将它们重构为表，因为它引入了一堆令人头疼的问题，包括更复杂的查询，处理在地址不存在等情况下，更多实体也会增加您的认知负担 - 这会使项目更难以思考。就我而言，这是一笔不必要的费用，因为没有具体的需要，事实上，甚至没有获得灵活性。
所以，根据我的经验，我会“尝试”将地址保存在同一个表格中，我肯定会将这些地址保留在它们上面 - 除非有特殊需要，否则。
所以用爱因斯坦的话来说，尽量简单，不要简单。但在短期内，实验。这是学习这些课程的最佳方式。
答案 3 :(得分：0)
提取它们。您的目标应该是在数据库中没有重复数据。 阅读Normalization
答案 4 :(得分：0)
这实际上取决于您要解决的问题。一般来说，拥有一些包含人员细节的“人”表可能是一个好主意。但是，在某些情况下，这可能是一个非常糟糕的主意。
一个例子是，如果您正在处理由医生写给人的处方细节。在一些国家，法律要求处方细节与其处方的名称一起举行，而不是该人目前的名称。例如，一名女性可能被处方药作为X小姐，但随后她结婚并成为Y女士。如果您有一张与处方表相关联的人员表，您现在会有错误的细节，并可能面临法律后果。在这种情况下，您可能需要将该人员的相关详细信息复制到处方表中，即使这会复制数据。
再次 - 这取决于你试图解决的问题。不要盲目追随人们认为的最佳做法。了解您的数据及其周围的任何问题，然后尝试遵循适合的最佳做法。
答案 5 :(得分：0)
作为对其他（完全有效）回复的对照：在您的应用程序的当前结构中，对于给定个体的可能性（不仅仅是名称，实际的“人” - 多个人可能是“John Smith” ）出现在多个表中？发生这种情况的可能性越小，从正常化中获益的可能性就越小。
另一种思考方式是实体。在标签（名称）之外，“客户”实体和“员工”实体之间是否有任何重叠？
答案 6 :(得分：0)
取决于您使用数据库的目的。
如果您想对表进行快速查询，则应该对表进行反规范化。必须运行多个JOIN将花费更长时间并使您的查询更复杂。
另一方面，如果您的目的是拥有一个灵活的存储数据库，并不打算用大量的快速响应查询，那么通过将表拆分为多个外部参照表来规范化表将提供更多设计的灵活性，减少提交重复数据的需要。
由于反规范化是“优化”，我建议您先对表进行规范化，正确编制索引，然后查看是否在查询中遇到任何瓶颈。如果是这样，请在需要的地方展平受影响的表格。
答案 7 :(得分：0)
您应该首先考虑整个数据库结构并首先执行ER图（实体关系图）。当然，应该有另一个名为“人”的表，其中存储了一个人的概念......