Database design 布尔变量与更具体的变量

在尝试创建更好、更一致的约定时，我希望获得以下选项的反馈。我使用的场景涉及记录物品是发送到现有地址还是新地址

这两种设置都会让人明白这一点，但它们的其他优点和缺点是我没有想到的，还是哪一个更好

    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.

---

企业需要什么？您是否试图表明发货地址已更改？您是否试图区分新地址或现有地址

那么，你为什么在乎呢？如果是新地址，您必须指明，以便将地址保存到数据库中？您需要报告发送到不存在地址的人数

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

---

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

答案是两者都不是

您提到的数据库，我假定它是指关系数据库管理器。您的设计不符合规则，需要修改以支持另一艘船，以便在最短的方便时间内（如客户尖叫时）解决问题

适当的数据结构是：

客户有无限多个订单

订单上有一艘船要处理

发送地址的数量是无限的

其中Customer、Order和Ship To都是独立的数据库表。至少在1970年之前，这被称为标准实践，并且已经成为标准实践

---

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

这取决于您试图完成的任务。如果您只想知道项目是否已发送到新地址，则布尔值为OK

---

我认为您需要考虑如何使您的体系结构具有可伸缩性。就像你在第一个“pro”中说的，你可能想要更多的选项，比如“临时地址”。如果需要更多确定性变量，可以始终使用枚举。

还有第三个选项：

• 将地址放在自己的表中（可能有一个

  owner

  列链接回您的用户/帐户表）
• 使用指向带有外键的地址表的

  ship_to

  列

优点：

• 每个人可以有他们需要的任意多个地址（家、办公室、小屋、朋友等等）
• 很好地正常化了

---

我能想到的唯一的缺点是你必须做更多的连接，但是连接并不是一件坏事。您可能需要进行更多的理智检查，以确保所有所有者都排列整齐，但这也没什么大不了的。

选项很容易记住——然后选择“N”（新）、“E”（现有）。如果需要，FK表（如果有）可以包含完整的“名称”。代码也将这些编码为所用语言中的常量<代码>字符串NewAddress='N'或其他任何东西。有趣的东西。不过，更多的细节可能会抵消这种做法。任务实际上是记录一个返回实例。考虑到这一点，备选地址在1-0无限规则中始终仅为“1”。谢谢你的链接-读得好。退货实例有多像订单？我可以想象它们非常相似，只是有一些细微的变化。客户能否从包含多行项目的订单中多次退货？这些将如何体现？如果你已经“烧掉”了新船，要在返程1号时住址，那么如果返程2号去了其他地方，你的日子会很难过。说这样的“不会发生”很容易，但一旦你的设计让它无法表现出来，它们往往就会发生。