Question

这更多是概念性的问题类型，用于存储和更新树的数据。让我们举一个常见的例子-来自React之类的虚拟dom。

用于表示dom的树的通用json存储类似于：

{
  nodeId: 'nodeId1',
  ...nodeData,
  childrenNodes: [
    {
      nodeId: 'nodeId2',
      ...nodeData,
      childrenNodes: [...]
    },
    ...
  ]
}

所以，我正在看一棵带有BFS或DFS的树（我相信React会使用DFS）来查找更改它的特定元素。

同一棵树的另一种可能的实现方式可能是我将其存储在更像哈希表外观格式的地方：

{
  nodeId1: {...nodeData, childrenNodes: [nodeId2]},
  nodeId2: {...nodeData, childrenNodes: [nodeId3, nodeId4]},
  ...
}

因此，获得特定节点的可能性可能为O（1），因为我们只是对所有节点ID进行哈希处理，而不必每次都遍历树。

对于诸如虚拟dom之类的东西，我们可以存储成千上万个可能的元素的状态，我认为在另一种之上存储一种方式可以忽略不计，但是我们可能不想拥有两种结构在内存中（尽管同时拥有两者可能会很好？）。

假设两个结构都为每个节点分配了ID，则在两种情况下添加和删除节点都非常容易。在这两种情况下，我们都可以假设每个子节点都有对其父节点的引用。

我要讨论的问题是，在一般情况下使用哪种结构更有意义，或者如果我们专注于尽快更新一个节点或一组节点，那么对这两个结构进行跟踪是否有意义？？如果我要从头开始构建框架，我会发现这两种情况对于不同的情况都是有用的，但是我必须牢记有限的存储设备，例如旧手机。

Answer 1

没有人回答，所以我将基于其他研究和观察给出我的意见。

在某些访问节点的方案中，提出的哈希解决方案会更快。但是，可读性强并且将此解决方案扩展到其他可能的集成，使它的处理起来要困难得多。如果我要使用这些ID数组，则希望将其作为一个单独的结构进行操作，仅用于搜索，而不能一次更新许多节点。

在大多数情况下，更详细的树轮廓将很有意义并且更易于使用。

JSON树存储格式

1 个答案: