问如何设计具有多个相关实体的数据库

EN

对于这种情况，如果您有严格的约定将单个属性it作为主键使用，则会有很大帮助，所有数据库模型都是相同的类型。

通过这一准备，您可以对具有属性"LinkedFromTable“、"LinkedFromID”和"LinkedToTable“和"LinkedToID”的通用“关系”表进行建模。"LinkedFromTable“和"LinkedToTable”属性必须包含您所引用的表的唯一标识符(可能只是表名)，LinkedFromID和LinkedToID使用引用数据行的主键值。

由于对ID列进行了适当的索引，“获取所有相关实体”的操作将非常便宜。

但请注意:缺点是您完全失去了这些“手动建模关系”的引用完整性--如果删除数据行，则必须手动检查和更新“关系”表。对于一个“写一次读-多”系统，这可能是好的，你必须自己决定。

您可以执行以下操作：

具有单个实体表-实体{id、type、ref_id_to_specific_entity_table}

具有单个关系表-关系{id1，id2}

这样，您就可以通过一个查询将所有相关实体都发送到给定实体。现在，如果您还想知道具体的关系而不需要获取第二个实体，您可以添加一个额外的列，就像可以使用关系{id1、relation、id2}那样。

这意味着，如果您进行更改，您必须担心一致性，但正如您所提到的，这是一个读取密集型的支持系统。可能没什么问题。

规范化给RDBMS带来了很多好处，但它也有一些倒退.当选择数据时，多重关系和复杂关系的性能可能会受到影响。

这个应用程序的主要目的似乎是提供报告，而不是由典型用户进行大量的数据修改。您可以保留当前结构来处理信息管理员对各种实体的所有数据输入/设置，但这并不意味着那些获得帮助信息的人必须查询这些完全相同的结构。

取决于您的帮助项被更改了多少，您可以非常容易地预先构建取消规范化的报表。它们基本上是查询的结果，而不对每个用户请求一遍又一遍地运行相同的查询。每种类型的请求都有自己的表。当帮助项更改时，将重新生成/更新/刷新该表。你得对这个进行编码。

还有很多其他的缓存工具，有些是内置在不同的数据库产品中的。这可能会变得更加昂贵和复杂。我会从这个开始。也许你可以选一个看看它是怎么工作的。无论您的应用程序使用的是实际运行的查询结果，还是对预构建表的简单查询，它都处理相同的数据，因此在您将越来越多的这些数据迁移到某个预先构建的表中时，很少需要在应用程序中进行更改。