【问题标题】:What is the best way for implementing customer phones, shipping details and order?实施客户电话、运输细节和订单的最佳方式是什么?
【发布时间】:2013-12-17 16:57:54
【问题描述】:

我需要为客户存储多部手机和运输详细信息。此外,当客户制作和订购时,他将能够从输入的电话/运输详细信息中进行选择。

例如,客户 1 可以有 3 部手机和 5 条送货详情。在订购时,他应该选择一部手机和一个送货地点。

从另一方面来说,我认为大多数人都会有一部手机和一个送货地点。

现在,我有两种方法。

  1. 表用户
    表地址
    表 UserAddress(来自用户和地址的多对多)
    桌面电话
    表 UserPhones(来自用户和电话的多对多)
    表顺序 - 两个字段:电话和地址,它们从适当的表中填充(作为字符串)。

    缺点是存储的是字符串,而不是引用。因此,空间利用率低。

  2. 表用户
    表地址
    表 UserAddress(来自用户和地址的多对多)
    桌面电话
    表 UserPhones(来自用户和电话的多对多)
    表 UserInfo(来自 UserAddress 和 UserPhone 的多对多)
    表顺序 - 一个字段:引用 UserInfo

    缺点是用户 ID 在 UserAddress 和 UserPhones 两个表中。

实现这种设计的最佳方式是什么?

【问题讨论】:

    标签: database-design


    【解决方案1】:

    使用第一种方法,但只需将Order 更改为UserPhoneIDUserAddressID(外键分别链接到UserPhone 中的主键IDUserAddress 中的ID)。

    这要求在下订单后立即创建 UserPhone 条目,并且用户只能将其配送到与其帐户关联的地址,但这是有道理的。

    由于一部手机(大概)不能属于多个用户,您可能希望完全废弃 UserPhone,只需在 Phone 中添加一个 UserID 字段。

    同样,废弃UserAddress 可能是有意义的,尽管保留它有两个好处:

    • 您无需为居住在同一地址的用户重复所有数据。
      这是为居住在同一地址的人重复地址和使用比居住在某个地址的唯一用户所需的更多空间之间的权衡。最好的选择实际上取决于数据。

    • 使用相同地址链接用户很容易,这可能对统计等有用。

    缺点是用户 ID 在 UserAddress 和 UserPhones 两个表中。

    这并不是真正的缺点。

    如果用户可以有多个电话或地址,这是最好的建模方法。

    【讨论】:

      【解决方案2】:

      为什么复杂?

      • 表用户
      • 表 UserAddresses(引用用户)
      • Table UserPhones(引用用户)
      • 表顺序(引用用户、用户地址和用户电话)

      【讨论】:

      • 想了想。不是很优雅,因为我们实际上存储了 3 次 userid。
      • 嗯,这就是在关系数据库中实现引用的方式。这不是冗余。
      • 谢谢。我认为这是最好的选择。
      猜你喜欢
      • 2017-05-17
      • 1970-01-01
      • 2017-11-19
      • 2017-12-18
      • 2022-11-09
      • 2022-01-26
      • 2010-10-25
      • 1970-01-01
      • 2021-04-22
      相关资源
      最近更新 更多