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

Question

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

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

还是留在一张桌子上？

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

Answer 1

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

Answer 2

这取决于那些“其他”细节是什么。这是一个普遍而有趣的问题，乍一看没有“硬性和快速”的答案。但是如果我们更抽象地思考这个问题，关于你想要表达的任何特定事物的属性（“细节”）之间的实际关系，我们可能会发现一些清晰度。

在你的问题中，你说朋友有“最小”和“其他”细节。我们不是将这些细节分类为“最小”或“其他”，而是根据朋友的独特之处是否可以完全确定任何个人（“原子”）细节来对它们进行分类。

我认为有一些主键（PK），如FriendID或电子邮件地址等。考虑到这个独特的标识符，请问自己：“如果我只给出了一个FriendID（或者电子邮件或者你用作PK的任何东西）那个朋友的详细信息我是否完全确定？例如，鉴于FriendID = 2112，我绝对是知道朋友的名字，姓氏和出生日期，但我不绝对知道朋友的电话号码，因为他们不止一个。

在一张表中将您在PK中明确知道的所有细节组合在一起。在“子”表中放置您需要更多数据的详细信息（如电话号码中的“home”或“work”），将外键键回到PK上的“parent”表。 （注意：子表的PK很可能是复合的;也就是说，由父表的PK和区分因子组成（在本例中类似于“home”或“work”）。多方的复合键1-M关系非常好。）

数据库极客基于功能依赖调用此分解。

Answer 3

毫无疑问：当逻辑上有意义时，总是将表分开。

例如：   朋友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个朋友住在里面怎么办？

如果您非常确定您的桌子很小，而且您不必查询它，那么您只能使用一张桌子。但是，除了你可以使用像sw这样的一些例外，或者说是一张纸： - ）

但是如果您想拥有一个数据库，请将其视为一个数据库。

了解整个问题的Normalization。