2

我需要存储一些与某些实体相关的评论标志。每个审查标志只能与单个实体属性组相关。例如，表Parents有一个ParentsStatus标志，表Children有一组ChildrenStatus标志。

在当前的设计方案中，我有三个表格：

  • ReviewTypes：存储标志和它们相关的属性。
  • ReviewPositions：存储标志可以具有的值。
  • Reviews：存储交易数据，实际评论。它就像 UsersToFlags:数据库行中的标志，最佳实践。

问题是我被拒绝了，不需要有Reviews表格，最好只在每个实体上存储这个实际的评论数据。例如添加一个额外的列Parents来保存ParentsStatus。他们认为这是一个更简单的解决方案，并且将数据分离出来对于外部场景来说只是“矫枉过正”。

我不喜欢这个想法，因为这意味着每次我们想要添加一个新的审查标志时，我们都需要更新核心实体表以保存该标志。

空间不是问题。

人们有什么强烈的意见吗？

编辑：

此评论适用于三个答案。共识是关系方法是最好的，但我认为我需要从一些非常基本的阅读了解 EAV 数据库模型的最佳初学者资源中阅读更多关于 EAV 模型的内容？及其相关链接似乎不是超级简单，我不想给自己挖个洞。感谢wildplasser。一旦我阅读更多内容，我将返回。

4

3 回答 3

3

哦是的。他们的想法更简单，直到你想增强它。鉴于该计划，他们提议如果每个实体需要两次审查，该怎么办。如果您想附加其他内容，例如注释/注释，该怎么办。一旦他们发现他们的想法是多少充气飞镖，你有什么要转向更有用的？更不用说您需要某种识别状态字段的方法，例如列名以“_Status”结尾的脆弱垃圾，或者您必须在某处对其进行硬编码。

正确地做这件事并没有那么多的工作，也没有更复杂，事实上在很多方面它更简单，并且可以以更低的成本应对不可逆转的变化。

于 2012-06-06T13:47:51.543 回答
2

归一化总是比过早优化更可取。

于 2012-06-06T14:19:42.820 回答
1

我喜欢单独的评论表的一个原因是，您可以保留您可能不想显示的更改（因为它尚未经过审核和批准）并仍然保留旧数据，直到新数据获得批准。不知道你的情况是否需要。

当您想要显示更改时，为了使将来的编程更简单，您可以编写一个显示旧数据和新数据的视图。

于 2012-06-06T14:15:38.053 回答