0

我有两张桌子：CHECKLIST_INSTANCE和CHECKLIST_CLASS

在CHECKLIST_INSTANCE我存储一个外键，CHECKLIST_CLASS_ID以便我知道该实例正在使用哪个清单。 

CHECKLIST_CLASS
   CHECKLIST_CLASS_ID
   REVISION
   NAME

CHECKLIST_CLASS 中的示例数据可能是： 

  1, A, ABC Checklist
  2, A, XYZ Checklist
  3, A, QWE Checklist
  4, B, ABC Checklist

现在的问题是修改。当我们修改清单时，我当前的策略是给它一个新的代理主键并更改 Rev（如清单ABC Checklist）

我觉得通过这种策略，我失去了CHECKLIST_CLASS_ID1 和 4 相关的关联。

如果我要更改设计以便使用组合 PKCHECKLIST_CLASS 

  1, A, ABC Checklist
  2, A, XYZ Checklist
  3, A, QWE Checklist
  1, B, ABC Checklist

然后我必须更改我的CHECKLIST_INSTANCE 表以将CHECKLIST_CLASS_REV 作为外键包含在内，然后我的所有查询也需要修改。

另一种选择是向CHECKLIST_CLASS. 分别为 PREVIOUS_REV_ID 或 NEXT_REV_ID

  using a PREVIOUS_REV_ID field
  1, A, ABC Checklist, null
  2, A, XYZ Checklist, null
  3, A, QWE Checklist, null
  4, B, ABC Checklist, 1

.

  using a NEXT_REV_ID field
  1, A, ABC Checklist, 4
  2, A, XYZ Checklist, null
  3, A, QWE Checklist, null
  4, B, ABC Checklist, null

使用最后两个中的任何一个，我都不必更改CHECKLIST_INSTANCE表或查询。关于最佳设计的任何想法？还是我应该调查另一种方法？

== EDIT 为明确起见，我不是在寻找对CHECKLIST_CLASS 表进行编辑的审计跟踪。

4

2 回答 2

2

这里的问题是，通过将修订添加到清单中，您不再有一个每个清单只有一行的表格。由于清单是一个不同的实体，您应该确保您拥有这样的表格。

我建议将修订移动到另一个表，因此您现在拥有三个表——checklist_class、checklist_class_revisions 和 checklist_instance 引用 checklist_class。checklist_class 仍然可以包含最新的清单修订，使清单修订表成为历史记录。

或者，如果需要将实例链接到修订，则清单修订表可以是清单实例的父级，从而提供三个表层次结构。

于 2013-10-15T21:31:45.593 回答
1

（回复我对@David 的回答的评论。）

这里有很多“取决于”。一种改写的模型是：[Checlikst] 有很多[Revisions]，[Revision] 有很多[Instances]。那将是三个与外键相关的表。问题是，这是否正确地代表了您尝试实施的商业模式？拥有三个独立的实体是否有意义？对此的答案将（最终部分）基于它们的使用方式。拥有一个独立于修订的 [Checklist] 实体和一个仅与清单的修订相关的 [Instance] 实体是否有价值和好处？或者 [Checklist/Revisions] 是否足够相互独立，以至于您真的不需要父/子关系？从表面上看，这是非规范化的数据，但如果没有真正的理由将它们规范化——如果它们不是独立的实体——那么不要给自己不必要的额外工作。（我，我会完全标准化，但我不知道你情况的全部细节。）

困难的部分是“水晶球”工作：你必须根据可能还不知道的因素做出决定（即你需要在一周、一个月、一年内做什么？）你越熟悉有了项目的目标和目的，你就能更好地做出这个决定。我的建议：花点时间，仔细考虑，并尽量避免你明天可能会后悔的草率决定。（你将有足够的时间为你将做出的明智的错误决定感到后悔，但你做出这些决定的借口会更好。）

于 2013-10-17T03:20:47.007 回答