核心数据中的文件夹结构 [英] Folder structure in core data

问题描述

我正在将文件夹结构存储在核心数据中.它反映了文件/文件夹的本地结构，并且每当用户在finder中执行任何操作(例如重命名/删除/创建)时都需要更新数据库.

I am storing folder structure in core data. Its reflecting local structure of files/folders and need to update DB whenever user perform any operation in finder(e.g. rename/delete/create).

我已经定义了单个实体节点(名称，fullPath，类型(dir/文件)).
节点实体与其自身之间的多对关系children，其删除规则设置为级联
节点实体与其自身之间的一对一关系parent，其删除规则设置为nullify.
并将它们设置为彼此成反比的关系.

I have defined single entity node(name, fullPath, type(dir/ file)).
a to-many relationship children from the node entity to itself, with the delete rule set to cascade
a to-one relationship parent from the node entity to itself, with the delete rule set to nullify.
and set these as inverse relationships of each other.

用户重命名文件夹时出现问题.目前，我正在更新节点并添加了通过父路径和子名称构造完整路径的方法.

I am having issue when user rename folder. Currently I am updating node and added method to construct full path via parent path and child name.

但是有时我需要通过路径获取节点，并且文件节点在重命名后不会更新.重命名后，我不想遍历文件夹中的所有文件.一些文件夹包含10万个节点.

But sometimes I need to fetch node via path and file nodes are not updated after rename. I don’t want to loop over all files inside folder after rename. Some folder contain 100k nodes.

任何人都可以帮助我或建议我做更好的设计吗?

Can anyone please help me out or suggest me better design ?

推荐答案

您已经创建了此问题，现在看到了它的影响.

You've created this problem and now you're seeing its effects.

• 您将完整路径存储在每个节点上
• 您的节点具有100k或更多的子节点
• 您希望能够重命名路径的任意部分

无论如何存储数据，都会造成一种情况，即有必要一次更新100k或更多节点上的字符串值.这是很多工作，而且不容易优化，因为您迟早必须计算和更新所有这些字符串.

No matter how you store the data, you've created a situation where it may become necessary to update string values on 100k or more nodes at once. That's a lot of work and it's not easily optimized, because sooner or later you have to calculate and update all of those strings.

真正的问题是，为什么要在每个节点上存储完整路径，并且可以设法停止这样做?

So the real question is, why are you storing the full path on every node and can you manage to stop doing that?

我不确定为什么要这么做.对于每个节点，您可以通过递归地遵循父级关系直到到达根节点来确定路径.同样，如果您具有完整路径并需要找到该节点，则可以使用路径定界符(可能是"/")将路径拆分为多个组件，然后通过子关系从根节点向下进行操作以获取路径.目标节点.

I'm not sure why you're doing it. For every node, you can work out the path by recursively following parent relationships until you reach the root node. Likewise, if you have a full path and need to find the node, you can split the path into components using the path delimiter (probably "/") and then work your way down from the root node via child relationships to get the target node.

这样做的好处是，如果您在树的中间某处重命名节点，就可以了！无需更新任何其他节点.

The nice thing about this is that if you rename a node somewhere in the middle of the tree, that's it, you're done! No need to update any other nodes.

最好将数据表示为 trie ，而不是简单地命名每个节点并链接其子节点，但这需要在Core Data中发挥一些创造力.我前段时间描述了一种可能的方法，但我并不一定声称这是最好的方法.除非您发现我上面描述的方法在实践中很慢，否则我不会尝试这样做.

It might be better to represent the data as a trie instead of simply naming each node and linking its child nodes, but that takes some creativity in Core Data. I described one possible approach a while ago but I don't necessarily claim it's the best one. I wouldn't try this unless you find the approach I describe above to be slow in practice.

这篇关于核心数据中的文件夹结构的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！