布尔变量与更具体的变量

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

答案是否定的。

您提到的数据库我假设是指关系数据库管理器。您的设计不遵循一零无穷规则，需要修改以支持另一艘船-在尽可能方便的时间（例如当顾客尖叫时）解决问题。

正确的数据结构是：

1. 客户有无限个订单
2. 订单有送货地址
3. 有无数个送货地址

其中客户、订单和送货地址都是单独的数据库表。这被称为第三范式，并且至少在 1970 年之前就已经成为标准做法。

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

Answer 2

业务需求是什么？您是否试图表明送货地址已更改？您是否想区分新地址或现有地址？

那么，你为什么关心呢？您必须指出以便将地址保存到数据库（如果是新的）吗？您需要报告有多少人运送到不存在的地址？

最后，你最终能有两个以上的选择（新的、现有的）吗？

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

Answer 3

还有第三种选择：

• 将地址放在自己的表中（可能有一个所有者列链接回您的用户/帐户表）。
• 使用通过外键指向地址表的 ship_to 列。

优点：

• 每个人可以根据需要拥有任意多个地址（家庭、办公室、别墅、朋友……）。
• 很好地标准化。

我能想到的唯一缺点是您必须进行更多连接，但连接并不是一件坏事。您可能需要进行更多的健全性检查，以确保所有所有权都很好地排列在一起，但这也没什么大不了的。

Answer 4

这完全取决于您想要实现的目标。如果您只想知道该商品是否运送到新地址，那么布尔值就可以了。

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