SQLite 结构建议答案

【问题标题】：SQLite structure adviceSQLite 结构建议
【发布时间】：2011-11-06 07:38:46
【问题描述】：

我有一个包含章节、子章节、章节、子章节、文章和未知数量的子文章、子子文章、子子子文章等的书籍结构。

构建这个的最佳方式是什么？一张有父子关系的表，多张表？

谢谢。

【问题讨论】：

【解决方案1】：

要确定是否涉及单独的表或一个大表，您应该仔细查看每个项目 - 章节、子章节等 - 并确定它们是否具有与其他项目不同的属性。章节是否包含与子章节不同的内容？

如果是这样，那么您正在查看 Chapter、SubChapter、Section、SubSection、Article 的单独表格。文章对我来说仍然有你的 sub-sub-sub-sub-sub-etc 的层次感。

如果不是，那么它可能是一张有父/子的大表，但看起来你可能在谈论层次结构深度的“名称”，这让我再次倾向于单独的表。

还要考虑您将如何查询以及您将搜索什么。

【讨论】：

如果数据是相同的，除了可能是某种“级别标识符”，那么就让它成为一个递归表。如果有不同的数据——比如说，章节有单独的作者但较低级别没有，文章有脚注但较高级别没有，等等——那么你需要不同的表格。我不会太教条，例如如果在一个级别上有一个额外的列，并且您可以无害地将其设置为其他级别的 null，好吧，将其保留在一张表中。但是，如果有很多差异，那么它们确实是不同的实体。
谢谢，我制作一张大桌子的唯一问题是，如果我有类似 Parent->child 1->child 2->child 3 之类的东西，例如，我如何选择 child 3 的 Parent。我需要通过查询来做到这一点。

【解决方案2】：

有几种方法可以在关系数据库中保存树结构。最常用的是使用父指针和nested sets。

第一个有一个非常简单的数据结构，即指向每个对象上各自父元素的指针），因此很容易实现。不利的一面是，由于无法完全遍历树，因此对其进行一些查询并不容易。每层都需要一个自连接。

嵌套集更容易查询（当您了解它的工作原理时）但更难更新。许多写入需要对树中的其他对象进行额外更新，这可能会使过渡保存变得更加困难。

第三种变体是materialized path 的变体，我个人认为这是前两者之间的良好折衷。

也就是说，如果您想存储任意大小的树（例如，对于节、子节、子子节......），您应该使用上述树实现之一。如果您的最大深度非常有限（例如最多 3 层），您可以创建显式数据结构。但由于事情总是比最初更复杂，我建议你使用真正的树实现。

【讨论】：