3

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

  PK| 姓名 | 类型 | 父母
  1 | 美国 | 国家 | 空值
  2 | 英国 | 国家 | 空值
  3 | 加利福尼亚 | 状态 | 1
  4 | 洛杉矶 | 城市| 3
  5 | 肯特 | 状态 | 2
  6 | 奥巴马 | 总统 | 1
  7 | 喀麦隆 | 下午 | 2

该表的主键将引用另一个表，该表将记录州/城市/国家在一段时间内的人口增长。

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

方法 1 比方法 2 有什么好处吗？查询是否更快？

4

3 回答 3

2

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

请记住，在以关系方式设计时，关系数据库工作得最好，不要在定义数据库表时使用面向对象的思维。如果你真的，真的需要 EAV 功能，至少在一个为这类事情更优化的 noSQl 数据库中做。

于 2012-05-02T17:01:39.607 回答
1

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

另一方面，如果您期望动态添加其他类型的“节点”（例如，州下的地区或市）和其他类型的关系（例如，某些国家可能根本没有州，因此城市应该直接“隶属于”国家） ，那么方法 1 增加的灵活性可能证明参照完整性的“脆弱性”是合理的。

如果做得好，这两种方法在性能方面应该表现得非常相似。

于 2012-05-02T16:53:25.313 回答
0

我认为这取决于您还想在数据库中存储什么（如果有的话）。例如，如果您想为其他实体存储特定国家/地区的数据，例如“首都”等，那么我将采用方法 2。但是，如果您需要表示的只是“人口组”，那么 1 似乎很好并且更简单。您的父 id 字段应该是一个外键，即同一张表上父的 pk。我会考虑将 type 作为 Type 表的外键，这样您就可以将其作为数字而不是字符串存储在主表中。只要您的键被索引，我怀疑您会看到性能上有很大差异。

于 2012-05-02T08:15:22.240 回答