业务概念设计与逻辑数据库设计

Question

日安。我需要一个特殊的案子的帮助。一个小背景:我们有一个现有的应用程序，它就像一个PDF查看器，你可以画徒手，高亮，添加高亮笔记，添加行动项目，等等。

在本讨论中，我将讨论两个数据库表: 1)包含文档操作项列表的ACTION_ITEM表；2)包含突出显示和注释的突出显示表。

高亮注释和操作项之间的区别在于，在操作项中，您可以将其分配给某人，指定到期日，并将其标记为已完成。

目前，我们添加了一个增强，以便最终用户将高亮注释转换为操作项。因此，我们添加了一个复选框"undefined操作项“。当您转换到一个操作项时，它的UX看起来仍然是一样的:它在视觉上仍然像一个便笺，它仍然与一个突出显示相关联，并且它仍然位于一个页面上，只是它被选中了"Action“。(我们的“通常”操作项，不与页面相关联)。

程序员(包括我)已经对增强进行了编码(这是在多个平台中编写的)，我们最了解的方式是:我们添加了所需的新列来突出显示表:截止日期、指定的人员、状态和操作项指示符。

下面是棘手的部分，正在进行设计讨论，以更改物理设计，将标记为操作项的突出显示信息转移到ACTION_ITEM表中。这意味着复制突出显示表中所需的所有列，如突出显示矩形、便笺位置、页码、文档id等，并将其复制到ACTION_ITEM表中。

这仅适用于高亮显示标记为操作项的注释。如果高亮注释未被标记为操作项，则仍然需要将其存储在突出显示表中。当前，将一个注释标记为一个操作项，我们只需更改一列，在新的设计中，我们必须将整个记录转移到另一个表。

不仅物理设计将发生变化，而且与其存储和检索相关的所有逻辑(这是很多)。

原因是，这位系统分析师说，我们需要将物理设计与业务概念结合起来，而不是为了方便而进行编程。在这种情况下，ACTION_ITEM是一个不同的业务概念，因此它需要在ACTION_ITEM表中。

我的问题是，系统分析师是对的吗？我们是否仅仅因为同一业务概念而合并同一表中的物理上不同的实体？作为一个程序员，我觉得这是不合逻辑的。这不仅是为了方便，也是为了效率。

Answer 1

我认为SA是对的。(在actions表中应该有操作)，但更具体的原因不只是“与业务定义保持一致”。

他说:通过添加exta cols来突出显示，您已经打破了该表的规范化。

他说:你大概是用行动来做事情的，现在你必须检查两个地方才能得到它们。打破了真理原则的单一来源。

显然，同样的理由也适用于“将突出显示字段复制到操作”，所以如果有这样的建议，您的SA也是错误的。

相反，我会增加一个行动和重点之间的联系。

即。

ACTION_ITEM
  Id
  FieldsForAction

HIGHLIGHT 
  Id
  FieldsForHighlight

HighlightsWithActions
  HighlightId
  ActionItemId

因此，当您勾选突出显示以使其成为一个操作时，您将填充一个新的ActionItem并向HighlightsWithActions中添加一行，指定所选的突出显示和您创建的新ActionItem的Id。

您可以添加唯一索引，以便根据需要将关系限制为1-0/1或1-多或多-多。

从长远来看，这将使编程变得更容易，因为业务会要求新的东西，比如“使所有的操作在周二都变红”等等。