Question

在尝试创建更好，更一致的约定时，我希望获得有关以下选项的反馈。我正在使用的方案涉及记录项目是运送到现有地址还是新地址。

这两种设置都可以解决这个问题，但是我们没有想到它们的额外优缺点，或者更好的惯例？

    field name: ship_to
       option 1: new_address
       option 2: existing_address

Pro: 
- Allows for new options down the road if needed.
- Easier to grasp what's going on when looking just a the database

Cons: 
- Not easier to grasp in the code - have to remember the options



    field name: ship_to_new_address
       option 1: true
       option 2: false

Pros / Cons - Pretty much the opposite of what I listed above.

Answer 1

答案都不是。

您提到的数据库我将假设为关系数据库管理器。您的设计不遵循one-zero-infinity规则，并且需要修改以在尽可能方便的时间（例如客户尖叫时）支持另一个送货地址。

正确的数据结构是：

客户有无限订单
订单具有收货地址
有无数的送货地址

Customer，Order和Ship-To都是单独的数据库表。这被称为Third Normal Form，至少在1970年以前就是标准做法。

如果您需要注意订单具有非标准的收货地址，请在订单中记录该布尔值。

Answer 2

业务需求是什么？您是否要指出送货地址已更改？您是要尝试区分新地址还是现有地址？

那么，你为什么关心？您必须指明，如果新的话，您将地址保存到数据库？您需要报告发送到不存在地址的人数吗？

最后，你有没有最终有两个以上的选项（新的，现有的）？

问题的答案将指出正确的方向。我个人的偏好是使用布尔如果只有两个选择，我认为没有必要扩展。但是，我使用外部API处理了很多，因此更改需要更多的思考，而不仅仅是内部的选项。枚举（通常将在数据库中存储为“类型表”）相当高效，性能良好，并且存储空间不会太大，因此它不是一个糟糕的选择。

Answer 3

这完全取决于你想要完成的事情。如果您只想知道项目是否被运送到新地址，或者布尔值是否正常。

我认为您需要考虑如何使您的架构可扩展。就像你在第一个“专业人士”中所说，你可能希望有更多的选项，比如“temporary_address”。如果你想要更多确定性变量，你总是可以使用枚举。

Answer 4

还有第三种选择：

将地址放在他们自己的表格中（可能会将owner列链接回您的用户/帐户表格。）
使用带有外键的地址表的ship_to列。

优点：

每个人都可以拥有所需的地址（家庭，办公室，小屋，朋友......）。
很好地规范化了。

我唯一能想到的是你必须做更多的连接，但连接并不是一件坏事。你可能需要更多的理智检查，以确保所有的所有权排队很好，但这也不是什么大问题。

布尔与更具体的变量

4 个答案: