数据库设计父子表与多个表

Question

我正在尝试为country-state-city-head创建父子关系。我考虑两种方法 - 1）创建一个表 -

  pk|  name             |       type       |       parent
  1 |  US               |      country     |       null
  2 |  UK               |      country     |       null
  3 | California        |      state       |       1
  4 | Los Angeles       |      city        |       3
  5 | Kent              |      state       |       2
  6 | Obama             |      president   |       1
  7 | Cameroon          |      pm          |       2

此表的主键将引用另一个表，该表将记录州/市/国家的人口增长。

2）第二种方法是为国家，州，首脑和城市创建多个表格 使用外键引用关系。 然后每个表（城市/州/国家）的主键将参考人口增长表

方法1是否有超过2的任何好处？查询速度更快吗？

Answer 1

方法1是一个EAV表，几乎总是最差的选择，除非你绝对无法提前预测你需要哪些领域（例如定义你可能希望从各种医学测试中存储的所有各种东西）。对于不会发生变化的地理数据，我会像瘟疫一样避免选项1。它更难查询，将成为阻塞争用的来源，通常只是一个坏主意。

记住关系数据库在以关系方式设计时效果最好，在定义数据库表时不要使用面向对象的思想。如果你真的真的需要EAV功能，至少要在noSQl数据库中进行，这个数据库更适合那种事情。

Answer 2

如果您的结构严格，请使用方法2.它可以让您精确定义参照完整性，因此您永远不会遇到（比方说）状态是父级的情况国家（而不是相反）。

另一方面，如果您预计动态添加其他类型的“节点”（例如州内的地区或城市）和其他类型的关系（例如某些国家可能根本没有州，所以城市应该直接“在”国家之下“，那么方法1的额外灵活性可能证明参照完整性的”脆弱性“。

如果做得好，两种方法的表现都应该非常相似。

Answer 3

我认为这取决于您想要存储在数据库中的其他内容（如果有的话）。例如，如果你想存储特定国家的数据，比如其他实体的“首都城市”等，那么我会选择方法2.但是，如果你需要代表的只是“人口群体”，那么1似乎很好而且更简单。您的父ID字段应该是外键，即对于同一个表上父节点的pk。我会考虑将Type作为Type表的外键，这样您就可以将它存储为主表中的数字而不是字符串。只要您的密钥被编入索引，我怀疑您会发现性能差异很大。