问题的标题可能没有很好地描述我的问题，但现在是：
假设我有一篇表格如下：
+ title
+ author
.
.
.
+ status [choices : ('draft', ..., 'translate')]
让我们说在我的业务流程中，我在我的网页上发布了[status ='translate']
的文章添加另一个字段是一个好的设计决定：
+ read [bool]
到我的表，这意味着文章已经准备好发布，或者它是一个糟糕的设计，因为我可以测试状态=='翻译'为此，新字段将只是重复？
我希望我的问题很明确，并提前感谢。
答案 0 :(得分：2)
这是一个基本的数据库设计概念（它实际上是使您的表符合3NF的一部分）：非您的列应该依赖于除表格的主键之外的任何内容。这应该回答你的问题。
这是一个很好的引用，要记住：
每个非关键属性
“必须提供钥匙的事实， 整个关键，只有关键 所以帮助我Codd“。
（也来自维基）
原因是违反这项法律可能会导致Data Integrity。
答案 1 :(得分：1)
糟糕的设计。
首先，你在这里所拥有的是一个基本上是状态引擎当前状态的字段。
其次，状态应该是一个单独的表 - 不要将状态文本放在同一个表中。然后，您可以将每种可能状态的其他信息添加到状态表中。
答案 2 :(得分：1)
重复。如果您可以在没有列的情况下进行管理，请不要使用它。
考虑一下它为数据库添加的开销（此外，布尔列无法编入索引，因此也不会提高性能）。
（当然，用数值替换状态字符串）。
祝你好运。答案 3 :(得分：0)
为了不存在潜在的数据完整性冲突，您可以将“就绪”列设为计算列，也可以创建提供此翻译服务的视图。
但是，对于这个特定的设计，我会将状态放入表中并在状态表中包含IsReady列。然后你可以添加所有IsReady的不同状态。我已经多次使用这样的设计，其中某些状态对于某些操作是等效的，但对于其他操作则不然。每个人都有一面旗帜。在我的特定情况下，许多不同州的批次被允许被计为“成功”用于平均时间/性能目的，但是已经完全成功但后来失效的批次不被认为是“成功”等等。
答案 4 :(得分：0)
此案例在归一化理论中有一个名称。它被称为“有害冗余”。以下是有害冗余的一些潜在缺点：数据库可能会自相矛盾;浪费了太多的空间;浪费了太多时间。
数据库中的矛盾在数据库设计教程中获得最多的播出时间。你必须采取一些措施来防止这种情况发生，或者承担后果。您可以依靠仔细的编程来保持数据库之外的矛盾，或者您可以声明约束，以防止任何事务使数据库处于矛盾状态。
浪费空间通常是一种微不足道的成本，但并非总是如此。浪费的空间可能导致浪费时间。
浪费时间是程序员最关心的问题。但在这里，问题变得更加微妙。有时“有害冗余”会节省时间，而不是浪费时间。大多数情况下，它会在更新期间产生额外的时间，但在检索期间会节省时间。通常，节省时间或浪费是微不足道的，因此从速度的角度来看，设计决策也是如此。
在您的情况下，速度后果应该是最小的。这是一个提示：您多久更新一次行？你多久阅读一次？更新或阅读的速度有多重要？如果你在阅读期间获得的时间比你花在更新上的时间更重，那就去吧。