Does that contradict "explicit is better than implicit"?
Yes, particularly when being explicit prevents you from implicitly shooting yourself in the foot. The "tree" in your example can have multiple parents claiming to own the same children. It can also have multiple root nodes (and it does: 2 is a root node; 4 is a root as well as a leaf node.)
This is a completely subjective question. The answer is, "it depends."
It depends on the primary use of your data. If you continually have to reference the nested structure, then it makes sense to represent it that way. And if you never reference the flat representation except when building the nested structure, then why have the flat structure at all?
The "flat" representation is one of the basics of the relational database model: each type of data exists in a table just for that type, and any relationships among the items are contained in separate tables. It's a useful abstraction, but at times difficult to work with in code. On the other hand, processing all the data of a particular type is trivial.
Consider, for example, if I wanted to find all the descendants of the record with id 2 in your example data. If the data is already in the hierarchy (i.e. native representation is the "nested" structure), then it's trivial to locate record id 2 and then traverse its children, children's children, etc.
But if the native representation is sequential as you've shown it then I have to pass through the entire data set to create the hierarchical structure and then find record 2 and its children.
将 Python（语言）的 Zen 与数据结构设计进行比较是毫无意义的。这两者的相似之处就像数字“2”和将一块奶酪分成“2”块一样。一个是事物，另一个是动作。
数据结构就是事物。
Python 描述动作。
should we apply the principle that "flat is better than nested" to data as well as to code?
No.
Even when there is a "logical tree structure" to the data?
That's what "flat is better than nested" doesn't apply to data. Only to code.
... the tree structure is obscured. Does that contradict "explicit is better than implicit"?
It's not even comparable. The "flat tree" is a common SQL implementation because SQL can't handle indefinite recursion of a proper tree.
Comparing the Zen of Python (the language) with data structure design is nonsensical. The two are no more comparable than than the number "2" and splitting a brick of cheese into "2" pieces. One's a thing, the other's an action.
I wouldn't inherently prefer either, but rather use whatever seems best suited to the task.
If the structure is important, nesting makes life simple. If you're regularly operating over each node, the flat structure makes it easy to use for node in tree. Of course, if you define your own class, its easy enough to abstract it so both options are simple; but it may be harder to use with external systems, such as converting to JSON.
“一切都应该尽可能简单，但不能更简单。”扁平比嵌套更简单。如果您正在处理具有相关嵌套的数据，那么将其展平可能会违反“但不简单”部分。相反，我采用 Python 的禅宗来鼓励您不要使用您并不真正需要的嵌套来使您的生活变得复杂，例如 XML 配置文件，其中更简单的平面格式可能就足够了。
"Everything should be made as simple as possible, but not simpler." Flat is simpler than nested. If you're dealing with data with relevant nesting, then flattening it probably violates the "but not simpler" part. I took the Zen of Python instead to be encouraging you not to complicate your life with nesting you don't really need, like an XML config file where a simpler flat format might suffice.
This question can't be answered "in general" - there is no right answer.
For this particular example, I actually like the tree structure better. Without knowing anything about the original application, and just looking at the structure, the relationship between the items is obvious. With the flat structure, I have to read some documentation, or application code to "know" that your tuple of children refer to id's.
The tree structure is self-documenting - the flat structure isn't.
发布评论
评论（6）
是的，特别是当显式可以防止你隐式搬起石头砸自己的脚时。你的例子中的“树”可以有多个声称拥有相同孩子的父母。它也可以有多个根节点（并且它确实: 2 是根节点；4 是根节点也是叶节点。）
Yes, particularly when being explicit prevents you from implicitly shooting yourself in the foot. The "tree" in your example can have multiple parents claiming to own the same children. It can also have multiple root nodes (and it does: 2 is a root node; 4 is a root as well as a leaf node.)
这是一个完全主观的问题。答案是“这取决于情况”。
这取决于数据的主要用途。如果您必须不断引用嵌套结构，那么以这种方式表示它是有意义的。如果除了构建嵌套结构时从不引用平面表示，那么为什么要使用平面结构呢？
“平面”表示是关系数据库模型的基础之一：每种类型的数据都存在于该类型的表中，并且项目之间的任何关系都包含在单独的表中。这是一个有用的抽象，但有时很难在代码中使用。另一方面，处理特定类型的所有数据是微不足道的。
例如，考虑一下，如果我想在示例数据中查找 id 2 的记录的所有后代。如果数据已经在层次结构中（即本机表示是“嵌套”结构），那么找到记录 id 2 然后遍历其子项、子项的子项等就很简单了。
但是如果本机表示是连续的，就像您已经显示后，我必须遍历整个数据集来创建层次结构，然后找到记录 2 及其子记录。
所以，正如我所说，“这取决于情况”。
This is a completely subjective question. The answer is, "it depends."
It depends on the primary use of your data. If you continually have to reference the nested structure, then it makes sense to represent it that way. And if you never reference the flat representation except when building the nested structure, then why have the flat structure at all?
The "flat" representation is one of the basics of the relational database model: each type of data exists in a table just for that type, and any relationships among the items are contained in separate tables. It's a useful abstraction, but at times difficult to work with in code. On the other hand, processing all the data of a particular type is trivial.
Consider, for example, if I wanted to find all the descendants of the record with id 2 in your example data. If the data is already in the hierarchy (i.e. native representation is the "nested" structure), then it's trivial to locate record id 2 and then traverse its children, children's children, etc.
But if the native representation is sequential as you've shown it then I have to pass through the entire data set to create the hierarchical structure and then find record 2 and its children.
So, as I said, "it depends."
不。
这就是“扁平优于嵌套”不适用于数据的原因。只能去打码了。
甚至没有可比性。 “扁平树”是一种常见的 SQL 实现，因为 SQL 无法处理适当树的无限递归。
将 Python（语言）的 Zen 与数据结构设计进行比较是毫无意义的。这两者的相似之处就像数字“2”和将一块奶酪分成“2”块一样。一个是事物，另一个是动作。
数据结构就是事物。
Python 描述动作。
No.
That's what "flat is better than nested" doesn't apply to data. Only to code.
It's not even comparable. The "flat tree" is a common SQL implementation because SQL can't handle indefinite recursion of a proper tree.
Comparing the Zen of Python (the language) with data structure design is nonsensical. The two are no more comparable than than the number "2" and splitting a brick of cheese into "2" pieces. One's a thing, the other's an action.
Data structures are things.
Python describes actions.
我本质上并不喜欢其中任何一个，而是使用任何看起来最适合该任务的东西。
如果结构很重要，嵌套会让事情变得简单。如果您经常对每个节点进行操作，则扁平结构可以轻松地使用
树中的节点。当然，如果您定义自己的类，则很容易对其进行抽象，因此这两个选项都很简单；但与外部系统一起使用可能会比较困难，例如转换为 JSON。I wouldn't inherently prefer either, but rather use whatever seems best suited to the task.
If the structure is important, nesting makes life simple. If you're regularly operating over each node, the flat structure makes it easy to use
for node in tree. Of course, if you define your own class, its easy enough to abstract it so both options are simple; but it may be harder to use with external systems, such as converting to JSON.“一切都应该尽可能简单，但不能更简单。”扁平比嵌套更简单。如果您正在处理具有相关嵌套的数据，那么将其展平可能会违反“但不简单”部分。相反，我采用 Python 的禅宗来鼓励您不要使用您并不真正需要的嵌套来使您的生活变得复杂，例如 XML 配置文件，其中更简单的平面格式可能就足够了。
"Everything should be made as simple as possible, but not simpler." Flat is simpler than nested. If you're dealing with data with relevant nesting, then flattening it probably violates the "but not simpler" part. I took the Zen of Python instead to be encouraging you not to complicate your life with nesting you don't really need, like an XML config file where a simpler flat format might suffice.
这个问题不能“一般地”回答——没有正确的答案。
对于这个特定的例子，我实际上更喜欢树结构。在不了解原始应用程序的任何情况下，仅查看结构，项目之间的关系是显而易见的。对于扁平结构，我必须阅读一些文档或应用程序代码才能“知道”您的子元组引用了 id。
树结构是自记录的，而平面结构则不然。
This question can't be answered "in general" - there is no right answer.
For this particular example, I actually like the tree structure better. Without knowing anything about the original application, and just looking at the structure, the relationship between the items is obvious. With the flat structure, I have to read some documentation, or application code to "know" that your tuple of children refer to id's.
The tree structure is self-documenting - the flat structure isn't.