存储分层数据的可能选项答案

【问题标题】：Possible options for storing hierarchical data存储分层数据的可能选项
【发布时间】：2012-05-17 17:20:46
【问题描述】：

我们需要能够在我们的 Web 应用程序中将各种类型的实体映射到不同类型的分层数据。例如，考虑一个名为 Vendor 的实体。我们需要能够将供应商的每个实例映射到地理区域。地理区域的等级如下：

我们拥有完整的邮政编码、地区、城镇、地区、省、地区、国家、地区和大洲的数据库。这目前作为 RDBMS 中的表存在。

我们的用例：

能够在任何级别将供应商与多个地区关联。例如，我们可以将 Nestle 映射到 欧洲大陆（一个区域）、加利福尼亚（美国一个省）和 大伦敦 em>（英国的一个地区）。
能够从映射中排除地理的某些部分。例如，当将 Nestle 映射到 California 时，我们可能希望排除 San Diego。
如果地理的组成发生变化，则不应要求对该地理所属的映射进行任何更改。例如，如果将邮政编码添加到大伦敦，则与雀巢的映射不需要更改。
能够在数据库中查询供应商和地理级别。例如，如果我们在数据库中查询 Nestle 和 邮政编码，我们应该得到 Greater London、California 的所有邮政编码（减去圣地亚哥的邮政编码）和欧洲大陆。如果我们在数据库中查询 Nestle 和 countries，我们应该得到 UK（Greater London 的国家），美国和欧洲大陆的所有国家。

这样的映射有很多不同类型的分层数据，这只是要求之一。

寻找有关存储分层数据和映射的建议。请不要发布涉及在 RDBMS 表中存储数据和映射的答案，因为我已经知道使用 RDBMS 的选项。

【问题讨论】：

如果您不是在寻找数据库解决方案，是否应该将此问题标记为 database-design？
我不是在寻找基于 RDBMS 的解决方案。可以有其他数据库解决方案涉及 NoSQL 数据库，如 Neo4j、Redis 等或分层数据库。
您是否有特定的原因要避免使用关系数据库？也许您认为这无法在关系数据库中表示？
正如我所提到的，我们已经在关系数据库中拥有地理数据。但是，至少有一些用例的性能很差。请详细阅读第 4 个用例，以了解为什么使用常规 RDBMS 对其进行建模时性能会受到影响。
@manish.in.java - 如果您使用我在回答中建议的模型，您的第 4 个用例将不会表现不佳。只要GEOGRAPHY 表有一个属性定义项目的层/级别，并且在层和左/右访问次数上有索引，那么检索将非常快。

【解决方案1】：

我知道您不是在寻找 RDBMS 解决方案，因为您“知道 RDBMS 的选项” - 但您没有说明您考虑过哪些选项以及您拒绝它们的原因。我相信可能有一个您没有考虑过的 RDBMS 选项，它具有数据维护量低和数据检索容易的优点。

我建议您将地理区域分组到具有内卷关系的单个表中 (adjacency model)。这允许您将供应商覆盖范围描述为地理覆盖范围记录列表。诀窍是尽可能高地记录供应商覆盖率。然后，您还可以列出覆盖范围的排除项。

这是一个建议的逻辑模型：

GEOGRAPHY 表可以使用nested sets 来简化分层地理数据的查询。

确定特定区域的供应商覆盖范围就像确认供应商对感兴趣的GEOGRAPHY（可能处于最低级别）拥有COVERAGE，同时又不在同一@ 的COVERAGE EXCLUSION 中一样简单987654328@.

【讨论】：