数据库设计：成员表分开还是全部在一张表中？答案

【问题标题】：DB design : members table separate or all in one table?数据库设计：成员表分开还是全部在一张表中？
【发布时间】：2010-11-08 09:12:57
【问题描述】：

我想创建一个包含个人信息和登录详细信息的朋友表。

最好将成员表分成 2 个表，一个包含最少的细节，第二个是其他细节。

还是留在一张桌子上？

我有很多包含成员外键的表。

【问题讨论】：

标签： mysql performance database-design members

【解决方案1】：

一个表，除非您可能需要将一个成员关联到多组详细信息（即多个电子邮件地址、用户组、白天电话、夜间电话、手机等） .

【讨论】：

如果您现在只需要一个，但以后需要更多怎么办？为什么要冒这个风险？
我假设用户已经计划好了他的业务和数据库。
@Peter，你的评论让我想到了 YAGNI。请注意不要使当前设计过于复杂，因为您以后可能需要它。
我同意。让自己过分沉迷于“假设”的心态会很快造成架构一团糟。我同意彼得的观点，即您应该考虑常见的事情，例如多个电话号码（如果您跟踪电话号码）等。
完全不一样，恐怕你把数据库设计和编程混为一谈......在现实世界中，所有的表都是分开的......

【解决方案2】：

毫无疑问：在逻辑上合理时，总是拆分表格。

例如：朋友1：汤姆琼斯住在山谷朋友 2 : Erin Jones 也过着他们的生活，因为它是他的兄弟

表格：

Friends
Id  Name          Address
1   Tom Jones     1
2   Erin Jones    1

Adresses 
Id Address
1  The valley

否则总是会出现这样的情况：

Friends
Id  Name          Address
1   Tom Jones     The Valey
2   Erin Jones    The Valley

这会导致错误的查询。

这只是一个问题，还有很多。如果有 2 个电子邮件地址和 3 个手机号码会怎样？如果街道名称发生变化并且有 5 个朋友住在其中怎么办？

如果您非常确定您的表会很小，并且您不必查询它，那么您可以只使用一张表。但是你也可以使用一些excell，比如sw，或者一张纸:-)

但如果你想拥有一个数据库，那就把它当作一个。

阅读Normalization 了解整个问题。

【讨论】：

我不同意你的地址示例，除非有情有可原的情况，否则我很难相信会有这么多“朋友”住在同一个地址，因此建模它是有益的大大地。但是，我同意电子邮件地址和电话号码应存储在不同的表中（除非您仅想要存储一个）
我在这里休息一下，数据库设计师（这是我的工作）我猜对程序员是一个无休止的斗争:-)

【解决方案3】：

这在很大程度上取决于那些“其他”细节是什么。这是一个常见而有趣的问题，乍一看并没有“硬性”的答案。但是，如果我们更抽象地考虑这个问题，关于您想要表示的任何特定事物的属性（“细节”）之间的实际关系，我们可能会发现一些清晰。

在您的问题中，您说朋友有“最少”和“其他”的详细信息。与其将这些细节分类为“最小”或“其他”，让我们根据是否任何个人（“原子”）细节可以完全由使朋友与众不同的因素来对它们进行分类。

我假设有一些主键 (PK)，例如 FriendID 或电子邮件地址或其他东西。考虑到这个唯一的标识符，问问自己：“如果给我一个 FriendID（或电子邮件或任何你用作 PK 的东西）我绝对确定那个朋友的哪些详细信息？例如，给定 FriendID=2112，我绝对知道那个朋友的名字、姓氏和出生日期，但我不绝对知道那个朋友的电话号码，因为不止一个。

根据 PK 将您明确知道的所有详细信息汇总在一张表中。将您需要更多数据的详细信息（如电话号码中的“家庭”或“工作”）放在“子”表中，外键返回到 PK 上的“父”表。（注意：子表的 PK 极有可能是复合的，即由父表的 PK 和区分因子（如本例中的“家”或“工作”）组成。多方的复合键1-M 的关系非常好。）

数据库极客根据功能依赖关系调用这种分解。

【讨论】：