MySQL地区/国家关系和正常化

我正在建立与区域、次区域、国家和国家区域的关系

我想要4层的原因是为了缩小搜索范围。例如，登录页面将有一张谷歌地图，显示整个世界，你可以点击任何区域（大陆），它可以通过其子区域缩放到该大陆，点击子区域以获取国家，如果该国家有国家区域，它将缩放到这些区域

我的问题是，并非所有地区/国家关系都有次区域

子_区域的一个示例是

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

---

我如何对其进行规范化，以便在没有子区域或国家/地区的情况下，数据仍然保持一致，InnoDB将乐于帮助我进行参考？

规范化应如下所示：

表1：

地区

id | region_name 

 id | sub_region  | country_id | region_type_id

表2：

国家

id | country_name | region_id 

表3：

地区类型

 id | region_type  (Southeast,Southwest etc)

表4：

子区域

id | region_name 

 id | sub_region  | country_id | region_type_id

---

把你所有的位置信息都放在一个表中，然后把它们放在一个树形结构中

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

---

我是否也需要一个sub_region表来使其成为3NF？请参阅更新。你想用每个分区来拯救国家地区吗？这与OP的要求完全不同。这种设计意味着一个国家可以有许多地区。当OP说

区域

时，他的意思是

大陆

。我遇到问题的地方是可选的Sub_Region列。我把这件事复杂化了吗？@Teez关系是一个地区可以有许多或没有次区域，次区域可以有许多国家，国家可以有许多或没有国家区域。。。我想这4个类别中的每一个都会有一个表，使其尽可能规范化。我一定会尝试一下。你混合的东西可能更好，不混合。例如，“北美”与自然地理有关，但“美国”与政治地理有关。如果你选择一个，你的生活就会变得简单。此外，有些国家由国家组成。（不是打字错误。）