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': ()} ]
(我使用元组是因为我不想让自己灵活地改变对象，直到这种灵 active 以明确的方式证明自己是有用和可用的。无论如何我永远不会使用 None在这里而不是一个空序列，因为它使逻辑复杂化，并且“特殊情况还不够特殊”-在这里，它一点也不特殊。)
当然这更短了，但是树结构是模糊的。这是否与“显式优于隐式”相矛盾？
我个人发现“平面优于嵌套”的适用性有限，与禅宗最重要的方面相去甚远。 (当然，如果我不允许自己进行大量嵌套，我就不能做很多我做的很好的函数式编程事情。)我怀疑“嵌套”的问题是当你理解信息时它需要上下文切换。我真的认为遵循命令式逻辑比解析数据或函数式代码更容易出现问题——在这种情况下，只需在脑海中命名嵌套 block ，并将其工作与外部上下文分开考虑。
你说什么？
最佳答案
这是一个完全主观的问题。答案是“视情况而定”。
这取决于您的数据的主要用途。如果您必须不断地引用嵌套结构，那么以这种方式表示它是有意义的。如果除了构建嵌套结构时您从不引用平面表示，那为什么还要使用平面结构呢？
“平面”表示是关系数据库模型的基础之一:每种类型的数据都存在于该类型的表中，并且项目之间的任何关系都包含在单独的表中。这是一个有用的抽象，但有时很难在代码中使用。另一方面，处理特定类型的所有数据是微不足道的。
例如，如果我想在您的示例数据中查找 id 为 2 的记录的所有后代。如果数据已经在层次结构中(即原生表示是“嵌套”结构)，那么定位记录 id 2 然后遍历它的 child 、 child 的 child 等是很简单的。
但如果 native 表示是顺序的，如您所展示的，那么我必须遍历整个数据集以创建层次结构，然后然后找到记录 2 及其子项。
所以，正如我所说，“这取决于。”
关于python - "Flat is better than nested"- 用于数据和代码？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/4372229/