我应该如何在数据库和 OOP 中建模组关系？答案

【问题标题】：How should I model a group relation in the database and in OOP?我应该如何在数据库和 OOP 中建模组关系？
【发布时间】：2010-10-04 19:12:46
【问题描述】：

我有 Item 的实例，我希望将它们分组到 ItemGroup 组中。但是如果Item 被移动到另一个项目组，出于责任原因，我想跟踪更改。例如。我需要知道 Item 在 10 月和 9 月是否在一个 ItemGroup 中。

我应该如何在数据库中对此进行建模？我应该如何在我的课程中对此进行建模，OOP？我可以看到一些不同的解决方案，但它们在某些方面都很复杂，所以我不知道如何实现它。

我可以选择三个表，ItemItemGroupGroupRelation，并在GroupRelation 上保留时间戳。如果项目信息更新，我需要创建一个新项目和一个新的 GroupRelation。如果项目更改组，我必须创建一个新的 GroupRelation。如果组信息发生更改，我必须创建一个新组和一个新的 GroupRelation。这很复杂，因为我必须在更改时创建多个新对象。

Item
+----+---------+-----+------+
| id | item_nr | ean | name |
+----+---------+-----+------+

ItemGroup
+----+------------+-----+
| id | group_name | vat |
+----+------------+-----+

GroupRelation
+----+---------+----------+-----------+
| id | item_id | group_id | timestamp |
+----+---------+----------+-----------+

另一种解决方案可能是只有两个类 Item 和 ItemGroup 但我需要在它们中都有一个时间戳，以便我知道它们何时更改。如果 Group 更新了，我必须更新属于该组的所有 Item，所以这也很复杂。

Item
+----+---------+-----+------+----------+-----------+
| id | item_nr | ean | name | group_id | timestamp |
+----+---------+-----+------+----------+-----------+

ItemGroup
+----+------------+-----+-----------+
| id | group_name | vat | timestamp |
+----+------------+-----+-----------+

可能还有其他解决方案，一种可能是将旧版本移到另一张桌子上。但是，当同时查找当前数据和旧数据时，搜索数据是否复杂。或者我可以有一个列prev_id 链接到旧版本。

有没有人有类似数据模型的经验并有任何建议？有没有针对此类问题的最佳实践？

【问题讨论】：

我没有遵循你的一些逻辑。为什么在更新某些信息时必须创建新项目/组？
@Joe：出于责任原因。旧版本必须保存。

标签： oop database-design data-modeling erp

【解决方案1】：

我会选择你的 Item、ItemGroup 和 GroupRelation 作为一个良好的规范化设计，重复最少。

您的审计要求可以建模为您需要审计的每个表（例如：ItemAudit、ItemGroupAudit），其中包含您需要审计的字段和时间戳。每次可审计字段更改时，您都会填充审计表。

这样，您就有了历史记录，并且不会用历史数据妨碍您的日常表格。

【讨论】：

谢谢，这看起来不错。我也需要GroupRelationAudit 吗？我认同。 OO设计怎么样，我认为两个类Item和ItemGroup就足够了，即使我有三个表Item，ItemGroup和GroupRelation，还是我走错了路？跨度>
@Jonas - 我不能告诉你你需要什么。如果您需要审核GroupRelation，那么是的，您可能也需要它。至于 OO 设计，Item 和 ItemGroup 对象应该足够了（只要其中一个有另一个引用）。您可能还希望收集每个历史数据的集合。
啊，听起来不错。我可以将ItemAudit-instances 保存在Item 的集合中。
@Jonas - 就是这样。也许使用延迟加载，所以如果你真的不需要它，你就不会得到所有的数据。

【解决方案2】：

根据您的描述，我认为有一个 GroupRelationHistory 的概念隐含在您的模型中。我会把它变成一个自己的实体，比如Item、ItemGroup 和GroupRelation。

在对象世界中，我会让Item 意识到它的GroupRelationHistory，这意味着Item 对象具有对GroupRelationHistory 对象的引用。本质上，GroupRelationHistory 只是一个由零个、一个或多个 GroupRelations 组成的列表。

引入这个概念应该得到实际业务需求的支持。去找你的客户（或某个代表），询问历史是否是一个独立的实体，是否具有一定的商业价值。如果是，请考虑这种方法并根据业务需求对其进行改进。然后考虑数据库模型，它高度依赖于具体的细化。如果不是，那么我会将历史概念作为纯审计功能，如建议的Oded。

【讨论】：