SQL table 或字段
SQL table OR field
我有一个概念性的问题。
我的数据库有一个 table 存储关于人的信息。它的字段之一是他们的 phone 编号（我所在的国家/地区为 8 位数）。
问题是在某些情况下，两个或更多人会有相同的 phone 号码。
我的问题是：将 phone 数字存储在另一个 table 上然后通过外键引用它而不是将它们存储为字段是否更好？如果是这样, 无论数据库大小如何，结果是否相同？
我不知道这是否会有所不同，但 table 的记录不会超过 600.000 - 800.000，我猜重合的 phone 数字大约为 10%总记录数。
编辑：
-每条记录最多可以有4个phone个数字（两行两格）
-这两种情况都会发生，有时用户会寻找所有具有特定号码的人，有时用户会想知道所有 phone 号码是什么人有
通常phone号只是一个号，没有人就没有意义。
所以你把它存储在 Person table.
但如果你在一家电话phone公司工作，其中一个phone号码有不同的含义和用途（如历史、phone查找、计费），那么它应该是存储在单独的 table 中。希望对您有所帮助。
如果每人超过 1 phone 个号码
设置新的 table 是有充分理由的：
id, user_id, phone, type, description
所以 type 可能是列表
家庭、工作、Office2、老板、妻子、传真、手机等...
和description喜欢
"work hours only"、"evening"、“24x7”、"Emergency only" 等
如果您真的为您的应用管理 phone 本书，那么将 phone 号码与原始用户 table 分开是个好主意。
如果您有两个人使用相同的 phone 号码，您将在搜索特定 phone 号码时遇到问题。搜索特定 phone 个数字有时会 return 多个结果（根据您的估计为 10%）。如果您按 phone 号码和人员搜索，则可以要求所有搜索 phone 号码的用户都包含用户标识符（名字、姓氏、位置等）。这取决于你的 objective 是什么。
从技术上讲，要标准化，您将有一个单独的 Phone 号码 table，然后是一个人 Phone 号码 table。
然而，在实践中，我很少看到 phone 号码和地址的这种结构。其一，当您只想更改一个时，很容易犯错误并更新多个人的地址或 phone。另一方面，它增加了一个对大多数人来说似乎不需要的额外连接。除了少量的重复之外，你并没有真正从这个级别获得太多收益。
真正的决定者是您将如何使用和更新这些数字。如果你想频繁地更新所有具有相同号码的人，最好完全归一化。如果您通常一次只想更新一个人，那么只有一个人 table 和一个人 Phone 号码 table 可能风险较小。
如果你想要历史，那么我会选择一个人table和一个人Phone数字历史table。它将包含 personid、phone 编号、开始日期和结束日期。因此，当 John 和 Mary 离婚时，他的 phone 号码会有结束日期，但她的号码不会，您可以清楚地看到谁在什么时候有号码。
我有一个概念性的问题。
我的数据库有一个 table 存储关于人的信息。它的字段之一是他们的 phone 编号（我所在的国家/地区为 8 位数）。
问题是在某些情况下，两个或更多人会有相同的 phone 号码。
我的问题是：将 phone 数字存储在另一个 table 上然后通过外键引用它而不是将它们存储为字段是否更好？如果是这样, 无论数据库大小如何，结果是否相同？
我不知道这是否会有所不同，但 table 的记录不会超过 600.000 - 800.000，我猜重合的 phone 数字大约为 10%总记录数。
编辑：
-每条记录最多可以有4个phone个数字（两行两格）
-这两种情况都会发生，有时用户会寻找所有具有特定号码的人，有时用户会想知道所有 phone 号码是什么人有
通常phone号只是一个号，没有人就没有意义。 所以你把它存储在 Person table.
但如果你在一家电话phone公司工作，其中一个phone号码有不同的含义和用途（如历史、phone查找、计费），那么它应该是存储在单独的 table 中。希望对您有所帮助。
如果每人超过 1 phone 个号码
设置新的 table 是有充分理由的：
id, user_id, phone, type, description
所以 type 可能是列表
家庭、工作、Office2、老板、妻子、传真、手机等...
和description喜欢
"work hours only"、"evening"、“24x7”、"Emergency only" 等
如果您真的为您的应用管理 phone 本书，那么将 phone 号码与原始用户 table 分开是个好主意。
如果您有两个人使用相同的 phone 号码，您将在搜索特定 phone 号码时遇到问题。搜索特定 phone 个数字有时会 return 多个结果（根据您的估计为 10%）。如果您按 phone 号码和人员搜索，则可以要求所有搜索 phone 号码的用户都包含用户标识符（名字、姓氏、位置等）。这取决于你的 objective 是什么。
从技术上讲，要标准化，您将有一个单独的 Phone 号码 table，然后是一个人 Phone 号码 table。
然而，在实践中，我很少看到 phone 号码和地址的这种结构。其一，当您只想更改一个时，很容易犯错误并更新多个人的地址或 phone。另一方面，它增加了一个对大多数人来说似乎不需要的额外连接。除了少量的重复之外，你并没有真正从这个级别获得太多收益。
真正的决定者是您将如何使用和更新这些数字。如果你想频繁地更新所有具有相同号码的人，最好完全归一化。如果您通常一次只想更新一个人，那么只有一个人 table 和一个人 Phone 号码 table 可能风险较小。
如果你想要历史，那么我会选择一个人table和一个人Phone数字历史table。它将包含 personid、phone 编号、开始日期和结束日期。因此，当 John 和 Mary 离婚时，他的 phone 号码会有结束日期，但她的号码不会，您可以清楚地看到谁在什么时候有号码。