关于地址、城市、国家数据的规范化问题答案

【问题标题】：Normalization question regarding address,city,country data关于地址、城市、国家数据的规范化问题
【发布时间】：2011-07-31 15:40:09
【问题描述】：

我目前有 3 个表存储有关世界上所有主要城市、与这些国家/地区对应的每个地区/州以及这些州/地区中的每个城市的信息。

现在我的数据库中有大约 6 个其他表，例如需要完全相同的 5 列的用户或组织表：地址、郊区、城市、州/地区、国家。所以我想知道使用存储这 5 条信息的“位置”表是否是“好的”规范化做法，然后用户或组织表将有一个 location_id 供参考。

好主意还是坏主意？我也在考虑在相同的原则中使用“联系人”表，其中包含 home_phone、business_phone、mobile_phone、email_address，而不是在 6 个表中的每一个中都有相同的 5 列。

任何建议表示赞赏。非常感谢！

【问题讨论】：

【解决方案1】：

这是一组不必要的关系 - 您可以改为从城市获取地区/国家/地区。

请注意，我在下图中的地区和国家/地区是错误的，但它说明了我的意思！

当然，定义一个结合城市、国家和地区的视图来实际编写查询会很有用。我也认为在实践中正常化到这个水平是一个非常好的主意。当您将一个新字段添加到您的位置表时，您会很高兴您已将其拆分出来 ;-)

【讨论】：

我这样做的唯一担心是用户不能只选择一个国家和/或地区/州。一些“城市”
我的网络应用程序当前的工作方式是用户在下拉列表中选择一个国家，它使用 AJAX 显示另一个下拉列表，其中包含该国家/地区的所有地区/州，然后该下拉列表使用AJAX 再次让用户选择该地区/州的城市。我想做的是让这些组织可以按国家、州/地区或城市进行搜索，这样当用户访问该站点时，他们可以在他们想要的区域找到这些组织。如果他们在那个城市找不到组织，那么他们需要能够按地区搜索，即使是小镇，它也应该找到它。

【解决方案2】：

我认为你已经做得过火了。地区、城市和国家作为单独的表格非常棒，因为您可以轻松管理条目而不会造成数据不一致。但是没有必要将每个用户/组织的地址数据存储在单独的（位置）表中。将这些字段添加到用户/组织表中。

编辑：RB 更详细地说明了它:)

【讨论】：