MySQL 地区/国家关系和规范化答案

【问题标题】：MySQL Region/Country Relationships and NormalizationMySQL 地区/国家关系和规范化
【发布时间】：2012-02-07 06:47:34
【问题描述】：

我正在创建与 Region、Sub_Region、Country 和 Country_Regions 的关系。

我想要 4 层的原因是为了缩小搜索范围。例如，登陆页面将有一个包含整个世界的谷歌地图，您可以单击任何区域（大陆），放大到带有 Sub_Regions 的大陆，单击 Sub_Region 以获取国家，如果该国家有 Country_Regions，它会放大到那些...

我的问题不是所有区域/国家关系都有一个子区域。

Sub_Region 的一个例子是

Region    |    Sub_Region         |    Country        |    Country_Region
Caribbean |    Lesser Antilles    |    Saint Martin   |    NULL
Europe    |    Iberian Peninsula  |    Spain          |    NULL

问题是如果我尝试把美国放到这个结构中，它看起来像这样：

Region         |    Sub_Region         |    Country         |    Country_Region
North America  |    NULL               |    United States   |    Southeast

我怎样才能规范化这个，如果没有 Sub_Region 或 Country_Region，数据仍然是一致的，InnoDB 会很高兴并帮助我参考？

【问题讨论】：

您正在混合可能更好地混合的东西。例如，“北美”与自然地理有关，而“美国”与政治地理有关。如果你选择一个，你的生活会变得更简单。此外，一些国家由国家组成。（不是错字。）

标签： mysql normalization

【解决方案1】：

标准化应该如下所示：

表 1：

地区

id | region_name

表 2：

国家

id | country_name | region_id

表 3：

region_type

 id | region_type  (Southeast,Southwest etc)

表 4：

子区域

 id | sub_region  | country_id | region_type_id

【讨论】：

我不需要一个 sub_region 表来使其成为 3NF 吗？
查看更新。你想用每个子区域保存国家区域吗？
这与 OP 的要求完全不同。这种设计意味着一个国家可以有很多地区。当 OP 说 Region 时，他的意思是 Continent。
我遇到问题的地方是可选的 Sub_Region 列。我是不是把事情复杂化了？
@Teez 关系是一个区域可以有很多或没有 Sub_Regions，一个 Sub_Region 可以有很多国家，国家可以有很多或没有 Country_Regions...我想每个人都会有一个表使其尽可能标准化的 4 个类别

【解决方案2】：

将所有位置信息放在一个表格中，并将它们放在树结构中

table location (
    id,
    title,
    location_type,
    fk_loc_parent,
)

【讨论】：

我一定会试一试的。