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

时间:2010-09-09 06:58:59

标签: database database-design

地理实体是:大陆,国家,省,市,邻里。默认情况下,Continent,Country和City将始终存在。省是可选的,因为并非所有国家都有州/省。邻域数据需要时间来查找,因此当数据进入时它就是一个负载。

其他实体: 邮政编码(映射到城市(必填)和邻居(可选))。 纬度/经度(映射到城市,社区,本地商家) 公司,品牌,本地业务(公司通过总部领域和公司位置领域映射到城市。品牌地图通过当地企业。如果本地商店存在于城市,那么品牌存在于城市。本地商店根据需要映射到城市和邻里可选。还需要将公司,品牌和本地商店与国家和全球层面联系起来。

所有这些数据都将是查找。那么为此制定模式的最佳方法是什么呢?1)我可以捕获所有关系,2)连接都很小,因为有大量其他表和实时数据 - 这意味着我需要保持关系的同等化? 3)确保数据更新很容易插入新数据,如果创建了错误的关系,很容易更改它?

那么每个实体应该获得自己的故事还是将它们全部扔进1-2个表中?除lat / longitue之外的这些实体中的每一个都将在现场可搜索,并且是用于分析的过滤器度量的一部分。

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

1 个答案:

答案 0 :(得分:1)

我将从规范化的数据库模式开始,使用它来直接思考。最初使用规范化数据库进行一些实验,根据需要添加索引以使查询执行。作为最后手段去标准化。

在这里,您似乎已经很好地定义了公司,品牌和LocalBusiness实体,您肯定需要这些表。

然后你似乎有一个位置,这是一个部分指定的地理概念。看起来Location与LocalBusiness是一对多的关系 - 可以(很少,但实际上可以)在完全相同的ZipCode或Lat / Long上有很多业务。

所以我会有一个具有许多可空字段的Location实体,包括CityId,NeighbourhoodId,Zip,Lat / Long。我认为只有CityId和Zip不可为空。

城市和社区需要得到巧妙对待 - 我认为在位置你有一个更复杂的实体的关键。因此,CityId将我们带到了City,其中包括省,州等.NeighbourhoodId带到邻居。我怀疑邻居是一个复杂的概念。我住在南爪哇岛,这是JavaVille的一个分区,是伦敦OobleDon区的一部分,也是米德尔塞克斯的行政区。