This问题让我思考：我们应该将“扁平比嵌套更好”的原则应用于数据还是代码？即使数据存在“逻辑树结构”？
在这种情况下，我认为这意味着将子项表示为ID列表，而不是实际的子列表，其中所有节点都在一个列表中：
[ {'id': 4, 'children': ()},
{'id': 2, 'children': (1, 7)},
{'id': 1, 'children': (6, 5)},
{'id': 6, 'children': ()},
{'id': 5, 'children': ()},
{'id': 7, 'children': (3,)},
{'id': 3, 'children': ()} ]
（我使用元组是因为我不愿意给自己灵活地改变一个对象，直到这种灵活性证明自己有用且可以清晰的方式使用。无论如何我永远不会在这里使用None而不是一个空序列，因为它使逻辑复杂化，“特殊情况不够特别” - 在这里，它并不特别。）
当然这个更短，但树形结构模糊不清。这是否与“明确胜过隐性”相矛盾？
我个人认为“扁平比嵌套更好”的适用性有限，并且远不及禅宗最重要的方面。 （当然，如果我不允许自己进行重要的嵌套，我无法做很多很好的函数式编程工作。）我怀疑“嵌套”的问题是当你理解信息时它需要上下文切换。我真的认为，在遵循命令式逻辑时，这比解析数据或函数式代码更容易出现问题 - 在这种情况下，更容易在心理上命名嵌套块，并将其工作与外部上下文分开考虑。
你说什么？
答案 0 :(得分：10)
这是一个完全主观的问题。答案是，“这取决于。”
这取决于数据的主要用途。如果你不得不引用嵌套结构，那么以这种方式表示它是有意义的。如果除了构建嵌套结构之外从未引用平面表示，那么为什么要使用平面结构呢？
“平面”表示是关系数据库模型的基础之一：每种类型的数据都存在于仅适用于该类型的表中，并且这些项之间的任何关系都包含在单独的表中。它是一个有用的抽象，但有时难以在代码中使用。另一方面，处理特定类型的所有数据是微不足道的。
例如，考虑我是否想要在示例数据中找到id为2的记录的所有后代。如果数据已经在层次结构中（即本机表示是“嵌套”结构），那么找到记录ID 2然后遍历其子项，子项的子项等是微不足道的。
但是如果本机表示是连续的，那么我必须通过整个数据集来创建层次结构，然后然后找到记录2及其子项。
所以，正如我所说，“这取决于。”
答案 1 :(得分：9)
我们应该将“扁平比嵌套更好”的原则应用于数据还是代码？
没有
即使数据存在“逻辑树结构”？
这就是“扁平比嵌套好”并不适用于数据。只有代码。
......树形结构模糊不清。这是否与“明确胜过隐性”相矛盾？
它甚至没有可比性。 “扁平树”是一种常见的SQL实现，因为SQL无法处理正确树的无限递归。
将Python的Zen（语言）与数据结构设计进行比较是荒谬的。这两者不比数字“2”更具可比性，并将一块奶酪分成“2”块。一个是对方，另一个是动作。
数据结构就是事物。
Python描述了动作。
答案 2 :(得分：7)
我不会天生偏爱，而是使用任何最适合任务的东西。
如果结构很重要，嵌套可以简化生活。如果您经常在每个节点上操作，则扁平结构使其易于使用for node in tree。当然，如果你定义自己的类，它很容易抽象它，所以两个选项都很简单;但它可能更难与外部系统一起使用，例如转换为JSON。
答案 3 :(得分：4)
“一切都应尽可能简单，但并不简单。” Flat比嵌套更简单。如果您使用相关嵌套来处理数据，那么展平它可能会违反“但不是更简单”的部分。我接受了Python的Zen而不是鼓励你不要用你真正不需要的嵌套来复杂你的生活，比如一个更简单的平面格式就足够的XML配置文件。
答案 4 :(得分：3)
这是否与“明确是否相矛盾” 比隐含的“？
更好
是的，尤其是当明确禁止你暗中射击自己的脚。您的示例中的“树”可以有多个父母声称拥有相同的孩子。它也可以有多个根节点（它确实：2是根节点; 4是根节点和叶子节点。）
答案 5 :(得分：3)
这个问题“一般”无法回答 - 没有正确的答案。
对于这个特定的例子，我实际上更喜欢树结构。在不了解原始应用程序的任何信息的情况下，只看结构，项目之间的关系是显而易见的。对于扁平结构，我必须阅读一些文档或应用程序代码，以“知道”您的孩子元组引用id。
树形结构是自我记录的 - 平面结构不是。