位置/品牌/公司 - 架构设计路线？

Question

地理实体是：大陆、国家、省、市、社区。默认情况下，Continent、Country 和 City 将始终存在。省是可选的，因为并非所有国家/地区都有州/省。并且邻里数据需要时间才能找到，因此数据进来时会很负荷。

其他实体： 邮政编码（映射到城市（必需）和邻里（可选））。 纬度/经度（映射到城市、社区、本地企业） 公司、品牌、本地业务（公司通过总部字段和公司位置字段映射到城市。通过本地业务映射品牌。如果本地商店存在于城市中，则品牌存在于城市中。本地商店根据需要映射到城市，社区可选。还需要将公司、品牌和本地商店与国家和全球水平联系起来。

所有这些数据都将被查找。那么为此创建架构的最佳方法是什么 1）我可以捕获所有关系，2）连接都很小，因为有大量其他表和实时提要数据 - 这意味着我需要保持关系去规范化？ 3) 确保数据更新很容易插入新数据，如果创建了错误的关系也很容易改变它？

那么每个实体应该有自己的故事还是将它们全部放入 1-2 表中？除了纬度/经度之外，这些实体中的每一个都可以在现场搜索，并且是分析过滤器指标的一部分。

编辑：我必须补充一下，这是一个基于“地理”的社交网络，将人们与当地城市联系起来，因此非常强调将所有系统对象与不同级别的位置联系起来。

Answer 1

我将从规范化的数据库模式开始，用它来让你的想法变得清晰。最初对规范化数据库进行一些实验，根据需要添加索引以执行查询。非规范化作为最后的手段。

在这里，您似乎已经很好地定义了 Company、Brand 和 LocalBusiness 实体，您肯定需要这些表。

然后您似乎有一个位置，这是一个部分指定的地理概念。位置似乎与 LocalBusiness 是一对多的关系 - 可以（很少，但实际上可以）有许多企业在完全相同的 ZipCode 或 Lat/Long 下。

因此，我将拥有一个包含许多可为空字段的 Location 实体，包括 CityId、NeighbourhoodId、Zip、Lat/Long。我认为只有 CityId 和 Zip 不能为空。

需要巧妙地对待城市和邻里 - 我认为在 Location 中，你有一把钥匙可以打开一个更复杂的实体。所以 CityId 将我们带到 City，其中包括省、州等。 NeighbourhoodId 将带到 Neighbourhood。我怀疑邻里是一个复杂的概念。我住在 South JavaVille，这是 JavaVille 的一个子社区，属于伦敦 OobleDon 自治市镇的一部分，位于米德尔塞克斯行政区。