电话号码在数据库模型中属于哪里？

Question

鉴于DVD租赁商店的架构，客户的电话号码是属于地址表还是用户表，为什么？一种方法或另一种方法是否有任何好处？

Answer 1

为什么你甚至拥有地址表（除非你想要一个给定客户的多个地址）？

您的主要“客户”是客户。您不会将DVD租借到某个地址，而是将其租给某个人。当乘客与你珍贵的“自由威利”收藏家版三部曲一起逃跑时，你不能把一块土地告上法庭。

在一个人只住在一个地方的世界里，地址将成为客户表的一部分（电话也是按照每个客户一个电话的方式）。

如果您想要多个地址，那很好，有一个单独的地址表将这些地址绑定回客户。

但你可能也应该有类似的手机设置。在customers表中允许每个客户最多N个电话号码（N列），或者（更好）拥有一个单独的电话表，允许每个客户使用任意数量的电话号码。

类似的东西：

customers:
    cust_id
    cust_stuff
addresses:
    cust_id references customers(cust_id)
    addr_seq_num
    addr_stuff
phones:
    cust_id references customers(cust_id)
    phon_seq_num
    phon_stuff

Answer 2

对此没有一个正确的答案，除了说“它取决于”。

这实际上取决于您使用数据库架构建模的内容。电话号码在逻辑上属于用户，还是可能由多个用户共享的地址？

示例 - 移动电话号码可能与特定人员绑定，因此成为用户表的一部分。固定电话号码可能与特定地点或住所相关联，因此也是地址的一部分。

Answer 3

信息建模的基本情况：

案例A.每个客户可以拥有多个电话号码。 在这种情况下，电话号码属于单独的表格。

案例A1。并非客户需要拥有电话号码。即，“关系”是1-1到0-n（即假设所有电话号码必须始终“为某个客户”）。无所事事。

案例A2。情况是每个客户确实要求拥有电话号码。你可以建模这个为1-1到1-n的关系，但是1-n部分的“1”在SQL系统中很难强制执行（并且在最便宜的SQL系统中） ，可能只是不可能）。这并不意味着您不应该正确地记录业务规则。

案例B.每个客户都有一个电话号码。

案例B1。每个客户必需都有一个电话号码。这意味着每个客户始终完全一个电话号码。电话号码最好放在客户表中。 （请注意，“有一个电话号码”的意思是“要知道有问题的电话号码！”

案例B2。客户不需要拥有电话号码。在正式的关系理论中，您需要定义一个仅包含已知电话号码的单独表格。在ER和UML等非正式建模技术中，您可以将其建模为“可选属性”。在SQL系统中，许多人会为此定义一个可为空的属性。

至于“电话号码”属于“地址”：电话号码和与您的业务相关的地址之间是否存在任何“连接”？我的意思是，假设一些客户有两个地址和两个电话号码。知道这两个电话号码中哪一个属于这两个地址中的哪一个很重要？手机号码属于哪个地址？

Answer 4

只是关于您的网站/应用的假设，但通常我会说“地址”，因为用户信息往往是您经常拉出来运行网站的信息（ID，用户名，访问等），而电话号码可能不是吗？

Answer 5

“传统”是什么意思？由于用户可以拥有任意数量的联系电话号码（家庭，工作，个人移动，工作移动，传真等），似乎应该有一个单独的电话号码表，每行包括一个号码和一个值，说明它是什么类型的数字。

Answer 6

在关系模式中建模联系信息非常困难。为了保持理智，我建议您就电话号码进行最少数量的分组。允许一个客户/帐户的多个电话号码是好的;除此之外，很难将规则应用于电话号码。

有一个众所周知的例外：许多披萨送货店使用电话号码作为客户的主要钥匙。这是有效的，因为通常有一个电话与一个传送披萨的地方相关联。另一方面，许多人不再拥有固定电话线，所以即使是那个系统也可能会崩溃。无论如何，我认为这不适用于DVD租赁。

Answer 7

不止一个客户可能拥有相同的电话号码：也许同一栋楼的多个人都会向您购买。

更新一位客户的电话号码时会发生什么情况;它应该更新那个应该分享该数字的其他人的数字吗？

• 是的，如果双方的地址仍然相同（但实际上可能违反了一些隐私法）。
• 否，如果现在有两个不同的地址。