0

让我们用一张表来存储客户发送给我们的消息。假设，如果客户要求我们向他们发送对他们发送给我们的信件的回复，我们还希望将其存储在该表中。如果他们已请求回复，那么我们会通过记录他们的电子邮件地址和预期日期来存储该信息。如果他们不想回复，我们不需要他们的电子邮件地址。

Correspondences
    Primary_key
    Content
    Date
    Response_expected
    Return address
    Return date

或者，我们可以完全去掉 response_expected 列，并同意返回地址/返回日期为空表示“预期没有响应”，非空则表示预期有响应。应用程序将负责使用此逻辑，而不是检查明确的“我们想要响应吗？” 场地。

（为了这个问题，假设有一个约束，因此返回地址和日期必须为空，除非预期的响应是肯定的......我的观点是该列不会被滥用或用于其他目的）

我的问题是：这种设计，应用程序必须同意解释数据的特定方式，是否可以接受？另一方面，我们存储的数据比我们需要的多，因为如果他们不期待回复，我们肯定不会有返回地址和日期

4

1 回答 1

2

我会为 Response_Expected 设置一个单独的列，就像您现在拥有的一样。是的，您可能有多余的信息，因为当预期没有响应时，返回地址将为 NULL。

然而，这两种想法是不同的。以下是您可能需要考虑的一些场景：

  • 将来，您有不止一种方法来返回响应。电子邮件只是一种渠道。这将使数据结构复杂化，但逻辑将依赖于单个通道。
  • 您发送了一封电子邮件，但由于某些其他原因它被退回或无法送达。
  • 响应变得依赖于其他一些标准。他们希望得到回应，但仅限于特定条件。

我不会担心数据的重复。我会更多地考虑应用程序的可持续性。

于 2012-09-04T22:04:24.670 回答