地理实体是：大陆，国家，省，市，邻里。默认情况下，Continent，Country和City将始终存在。省是可选的，因为并非所有国家都有州/省。邻域数据需要时间来查找，因此当数据进入时它就是一个负载。
其他实体： 邮政编码（映射到城市（必填）和邻居（可选））。 纬度/经度（映射到城市，社区，本地商家） 公司，品牌，本地业务（公司通过总部领域和公司位置领域映射到城市。品牌地图通过当地企业。如果本地商店存在于城市，那么品牌存在于城市。本地商店根据需要映射到城市和邻里可选。还需要将公司，品牌和本地商店与国家和全球层面联系起来。
所有这些数据都将是查找。那么为此制定模式的最佳方法是什么呢？1）我可以捕获所有关系，2）连接都很小，因为有大量其他表和实时数据 - 这意味着我需要保持关系的同等化？ 3）确保数据更新很容易插入新数据，如果创建了错误的关系，很容易更改它？
那么每个实体应该获得自己的故事还是将它们全部扔进1-2个表中？除lat / longitue之外的这些实体中的每一个都将在现场可搜索，并且是用于分析的过滤器度量的一部分。
编辑：我必须补充一点，这是一个基于“地理”的社交网络，将人们与当地城市联系起来，因此非常重视将所有系统对象与不同级别的位置连接。
答案 0 :(得分：1)
我将从规范化的数据库模式开始，使用它来直接思考。最初使用规范化数据库进行一些实验，根据需要添加索引以使查询执行。作为最后手段去标准化。
在这里，您似乎已经很好地定义了公司，品牌和LocalBusiness实体，您肯定需要这些表。
然后你似乎有一个位置，这是一个部分指定的地理概念。看起来Location与LocalBusiness是一对多的关系 - 可以（很少，但实际上可以）在完全相同的ZipCode或Lat / Long上有很多业务。
所以我会有一个具有许多可空字段的Location实体，包括CityId，NeighbourhoodId，Zip，Lat / Long。我认为只有CityId和Zip不可为空。
城市和社区需要得到巧妙对待 - 我认为在位置你有一个更复杂的实体的关键。因此，CityId将我们带到了City，其中包括省，州等.NeighbourhoodId带到邻居。我怀疑邻居是一个复杂的概念。我住在南爪哇岛，这是JavaVille的一个分区，是伦敦OobleDon区的一部分，也是米德尔塞克斯的行政区。