存储分层数据的可能选项

Question

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

1. 邮政编码 - 最细粒度的地理区域;例如， EC2
2. 地点 - 由邮政编码组成;例如，肯辛顿。每个邮政编码都只是一个地方的一部分，不再是。
3. 城镇 - 由地方组成;例如伦敦。每个地方都将成为一个城镇的一部分，不再是。
4. 区 - 由城镇组成;例如，哥伦比亚。
5. 省 - 由地区组成（相当于某些国家的州）;例如，南卡罗来纳州。
6. 地区 - 由各省组成;例如，东北省。
7. 国家 - 由地区组成。
8. 区域 - 由国家组成;例如东南亚。
9. 大陆 - 由区域组成。

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

我们的用例：

1. 能够在任何级别将供应商与多个地理位置相关联。例如，我们可以将雀巢映射到欧洲大陆（区域），加利福尼亚（美国省份）和大伦敦 em>（英国的一个地区）。
2. 能够从地图中排除地理的某些部分。例如，将雀巢映射到 California 时，我们可能希望排除 San Diego 。
3. 如果地理的构成发生变化，则地理位置的映射不需要进行任何更改。例如，如果将帖子代码添加到大伦敦，则使用 Nestle 的映射不需要更改。
4. 能够在数据库中查询供应商和地理级别。例如，如果我们在数据库中查询雀巢和邮政编码，我们应该获取大伦敦，加利福尼亚州的所有邮政编码（减去 San Diego 的邮政编码）和欧洲大陆。如果我们在数据库中查询雀巢和国家，我们应该获得 UK （大伦敦的国家/地区），< em>美国以及欧洲大陆的所有国家。

有许多这样的映射具有许多不同类型的分层数据，这只是其中一项要求。

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

Answer 1

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

我建议您将地理区域划分为一个具有复杂关系的表格（adjacency model）。这允许您将供应商范围描述为地理覆盖记录列表。诀窍是在最高级别记录供应商的覆盖范围。然后，您还可以列出覆盖范围的排除项。

以下是建议的逻辑模型：

GEOGRAPHY表可以使用nested sets来简化查询层次结构地理数据。

确定特定区域的供应商覆盖范围就像确认供应商对COVERAGE感兴趣的GEOGRAPHY（可能处于最低级别）而不是{{1}同样的COVERAGE EXCLUSION。