如何设计具有父子关系的数据库？答案

【问题标题】：How to design DB with parent-child relationships?如何设计具有父子关系的数据库？
【发布时间】：2011-04-05 00:05:38
【问题描述】：

如果我需要在数据库中表示位置（例如国家、州/省/地区、城市等），我将如何以最容易查询、扩展大多数等？我计划将其用于允许用户选择多个位置并将它们与他们的个人资料相关联的应用程序。

想到的解决办法是这样的：

===========================
| Id | ParentId | Name    |
===========================
| 1  | 0        | USA     |
---------------------------
| 2  | 1        | Alabama |
---------------------------

我想知道这样的解决方案是否存在任何潜在问题。谢谢。

【问题讨论】：

标签： database-design normalization

【解决方案1】：

如果您知道不同类型的项目（城市国家/地区），您应该创建单独的表格。将它们全部放在一张表中会使查询变得更加困难。

如果您使用不同的表类型，您可以强制执行参照完整性，这样就不会出现孤儿。

想想孩子们！

【讨论】：

您可以在自联接中强制引用完整性。您只需要为没有父母引用的行制定规则，无论是他们自己还是指定的“根”记录。
我不认为我知道所有不同类型的项目。不同的国家划分的地理区域不同。我需要一个支持 n 级层次结构的设计。
@StackOverflowNewbie - 我明白了，那么你的设计很好而且很有意义。但是投票者愿意解释吗？在我发布我的答案之前，我无法预测他的评论......
+1 想想孩子们！。同意分离项目，我正在使用 parent_id 方法作为节点结构。

【解决方案2】：

这似乎相当适合可扩展性，但是我可能会包含一个额外的列来标识实际的行/条目（如果你愿意的话，实体类型）。

这将允许您根据选择（国家、城市等）轻松查询。您可能会发现，分层结构可能会给您带来一些痛苦，因为整个结构将在一个表中，并且您不知道开始的深度。

最终，设计将取决于您可能拥有的子部分的已知数量，而这种标准化实际上是否会使生活变得更加困难，而不是没有。

【讨论】：

如果我事先不知道我有哪些“类型”怎么办？

【解决方案3】：

根据您的受众，您可能还需要考虑按类型分离名称值，以便在不复制层次结构的情况下进行本地化。

【讨论】：

您能详细说明一下吗？ DB 设计中的名称/值对也存在自己的问题。

【解决方案4】：

我使用了类似的东西，并取得了很大的成功。最近的Question of mine 可能会派上用场。

在某些情况下（例如这种情况）我不想被绑定到表结构。自我引用可能是一件好事。我不明白为什么在代码中使用相同对象类型的树状结构如此受欢迎，但在涉及数据库时却被程序员回避。

【讨论】：