数据库设计：成员表是单独的还是全部在一张表中？
我想创建一个包含个人信息和登录详细信息的朋友表。
将members表分成2个表更好， 一个包含最少的细节， 其次是其他细节。
还是留在一张桌子上？
我有很多包含成员外键的表。
I want to create a table of friends with personal information and log on details.
What better to separate the members table to 2 tables ,
one contain minimal details ,
second with Other details.
or remain in one table ?
i have a lot of tables that contain the foreign key of the member.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
这在很大程度上取决于那些“其他”细节是什么。 这是一个常见且有趣的问题，乍一看并没有“一成不变”的答案。 但是，如果我们更抽象地思考这个问题，关于您想要表示的任何特定事物的属性（“细节”）之间的实际关系，我们可能会发现一些清晰的情况。
在您的问题中，您指出朋友拥有“最少”和“其他”详细信息。 我们不是将这些细节分类为“最小”或“其他”，而是根据任何个人（“原子”）细节是否可以完全由朋友的独特之处来确定。
我认为有一些主键（PK），比如 FriendID 或电子邮件地址之类的。 考虑到这个唯一的标识符，问问自己：“如果给我一个 FriendID（或电子邮件或任何您用作 PK 的东西），我绝对确定该朋友的哪些详细信息？例如，给定 FriendID=2112，我绝对确定该朋友的哪些详细信息？知道该朋友的名字、姓氏和出生日期，但我不绝对知道该朋友的电话号码，因为其中不止一个将
您的所有详细信息明确地分组在一张表中 。将需要更多数据的详细信息（例如电话号码的“家庭”或“工作”）放入“子”表中，并用外键返回到 PK 上的“父”表（注意：子表的 PK 很可能是复合的；即，由父表的 PK 和区分因素组成（如本例中多方的“home”或“work”复合键）。 1-M 关系非常好。）
数据库极客将这种分解称为基于函数依赖。
It depends a lot on what those "other" details are. This is a common and interesting question, and there is no "hard and fast" answer at first glance. But if we think of the issue more abstractly, about the actual relationship among the attributes ("details") of any particular thing you want to represent, we may find some clarity.
In your question you state that friends have "minimal" and "other" details. Rather than classifying these details as "minimal" or "other", let's classify them by whether or not any individual ("atomic") detail can be fully determined by whatever makes a friend unique.
I presume there is some primary key (PK), like FriendID or e-mail address or something. Considering this unique identifier, ask yourself: "If I'm given exactly one FriendID (or e-mail or whatever you are using as PK) what details of that friend am I absolutely sure of? E.g., given FriendID=2112, I absolutely know that friend's first name, last name, and date of birth, but I do not absolutely know that friend's phone number because there is more than one of them.
Group together in one table all the details you unambiguously know given the PK. Put the details for which you need more data (like "home" or "work" in the case of phone numbers) in "child" tables, foreign-keyed back to "parent" table on the PK. (Note: It's extremely likely that the PK of the child table will be composite; that is, composed of the parent table's PK and the differentiating factor (like "home" or "work" in this example). Composite keys for the many side of 1-M relations are very good.)
Database geeks call this decomposition based on functional dependencies.
一张表，除非您可能需要将一名成员关联到多组详细信息（即多个电子邮件地址、用户组、白天电话、夜间电话、手机等）。
One table, unless you potentially need to associate one member to multiple sets of details (ie multiple email addresses, user-groups, day-phone, night-phone, cell-phone, etc).
毫无疑问：当逻辑上有意义时，总是拆分表。
例如：
朋友 1：汤姆·琼斯住在山谷
朋友 2：Erin Jones 也住他们的桌子，因为这是他的兄弟
桌：
否则总会出现这样的情况：
这会导致错误的查询。
这只是一个问题，还有很多。 如果有 2 个电子邮件地址和 3 个手机号码怎么办？ 如果街道名称更改并且有 5 个朋友住在其中怎么办？
如果您非常确定您的表很小，并且您不必查询它，那么您可以只使用一张表。 但是你也可以使用像 sw 这样的 excel，或者一张纸:-)
但是如果你想拥有一个数据库，就把它当作一个数据库。
阅读整个问题的标准化。
No question about it : always split up tables when it makes sense logically.
Eg :
Friend 1 : Tom Jones lives in The Valley
Friend 2 : Erin Jones lives their too since it's his brother
tables :
Otherwise things always will come up like :
Which will lead to erroneous queries.
That's just one issue, there are numerous. Like what if so has 2 e-mail addresses and 3 cell phone numbers? What if a streetname changes and 5 friends live in it?
If you are very sure your table will be small, and you don't have to query it, than you could use just one table. But than you can just use some excell like sw too, or a piece of paper for that matter :-)
But if you want to have a database, treat it as one.
Read about Normalization for the whole issue.