我正在研究一个我继承的数据库，我发现了一些我不确定是一种好习惯的方法。
基本上有一个状态表，其中包含StatusID和描述的列表。有两个表与FK关系。在两个表之间存在共同状态（基本上相同的描述）和一些对于单个表是唯一的。
除此之外，还有另一个“类型化”状态表，它只与单个表（不是前两个）相关。
表1 ----＆gt; StatusTable＆lt; -----表2表3 ----＆gt; Table3Status
在我看来，'typed'状态表在第一个之后添加了一段时间，可能来自不同的开发人员。我的问题是我应该合并第二个状态表并使其在整个数据库中保持一致，还是应该将组合使用表分开？
我想第三种选择是将状态表'StatusTypeID'中的另一个字段添加到定义状态的表中。[/ p>
思想？
编辑： 更具体： 这三个表是（并且我不宽恕Tbl前缀）TblVersionEvaulationFormulaire，TblEvaluationMandat和TblRecontreCarriere。 IE TblVersioning，TblMidtermEvaluations，TblCareerInterestsAndExperience。 Versioning表跟踪其他两个表更改。 IE如果中期评估的标准发生变化，我会创建它的新版本并将其添加到Versioning表中。与TblCareerInterestsAndExperience相同。因此，例如，所有三个表的状态均为已发布，但每个表都具有唯一的状态。我想我应该将表分开，或者在状态表中添加第三列来区分。
答案 0 :(得分：1)
如果它们都是特定类型的状态类的状态表，则最简单的方法是拥有单一状态表，并让三个表中的每一个都向其声明外键。
您始终可以根据哪些状态不适用，向引用状态表的特定表添加约束。您可以通过明确地分解状态来更优雅地执行此操作，以便查询可以作为约束的基础（即，没有硬编码的“IN”子句）。您可能需要在状态表中至少添加一个额外列，以帮助将状态类分解为子类别。
如果table3确实使用了不同类型的状态，那么它需要自己的表。所有这一切都有一个语义元素 - 你需要问自己一个特定类型的状态是否可以想象/与特定表相关。如果没有，那么合并所有状态可能是不可行的。
例如，在我的系统中，我可能有ORDER STATUS和SYSTEM STATUS。这是两个非常不同的类，我无法想象某个行项目可能 订单状态或系统状态的情况。我需要两张桌子。但是，如果我有ORDER PRE-PROCESSING_STATUS和ORDER POST-PROCESSING STATUS，那么这些可能会合并到一个类中。所以这里需要在逻辑层面进行健全性检查。
答案 1 :(得分：0)
如果Table3Status和StatusTable是不相交的，那么我就把这个单独留下，并认为它只是命名不好，因为它意味着它们完全用于不同的目的。
表1和表2应该合并，原因很明显。
以防它有用......我在日常工作中使用的bug跟踪器数据库有一个分类系统，其中“问题”都在一个表中，并按索引字段类型，用途和产品进行划分。这三个的每个排列都可以为其分配自定义状态集，如果没有特定组合适用于某个问题，则它会通过3个级别的默认状态集回退。所有状态集都存在于一个表中。