我需要为客户存储多个电话和送货详情。此外,当客户订购和订购时,他将有能力从他输入的手机/运输细节中进行选择。
例如,客户1可以拥有3部电话和5个发货详细信息。在订购期间,他应该选择一个电话和一个送货地点。
另一方面,我认为大多数人会有一部电话和一个发货地点。
现在,我有两种方法。
表用户
表地址
表UserAddress(来自用户和地址的多对多)
台式电话
表UserPhones(用户和电话中的多对多)
表顺序 - 两个字段:电话和地址,它们从适当的表中填充(作为字符串)。
缺点是存储字符串而不是引用。因此,空间使用效率低下。
表用户
表地址
表UserAddress(来自用户和地址的多对多)
台式电话
表UserPhones(用户和电话中的多对多)
表UserInfo(来自UserAddress和UserPhone的多对多)
表顺序 - 一个字段:对UserInfo的引用
缺点是用户ID在UserAddress和UserPhones两个表中。
实施此类设计的最佳方式是什么?
答案 0 :(得分:0)
使用第一种方法,但只需将Order
更改为UserPhoneID
和UserAddressID
(外键链接到ID
和UserPhone
中的主键ID
分别在UserAddress
中{1}}。
这要求,只要下订单,就会创建UserPhone
条目,并且用户只能投放到与其帐户相关联的地址,但这是有道理的。
由于手机(可能)不属于多个用户,因此您可能想要完全废弃UserPhone
,只需在UserID
中添加Phone
字段。
同样,废弃UserAddress
可能有意义,尽管保留它有两个好处:
您不需要为居住在同一地址的用户重复所有数据 这是为居住在同一地址的人重复地址和使用比生活在某个地址的唯一用户所需的空间更多的空间之间的权衡。最好的选择实际上取决于数据。
使用相同的地址轻松链接用户,这可能对统计用途有用。
缺点是用户ID在UserAddress和UserPhones两个表中。
这不是一个真正的劣势。
如果用户可以拥有多个电话或地址,这是对此进行建模的最佳方式。
答案 1 :(得分:0)
为何复杂化?