在 jcr 存储库中组织文件的正确方法

发布于 2024-09-04 10:55:22 字数 464 浏览 0 评论 0原文

在使用 JCR 的 wcm 中组织文件的正确方法是什么？假设总文件数为 100,000+ 个文件，总文件大小约为 50-70GB。按fie类型组织文件是否更好（并创建子目录以进一步按某种类别对文件进行分组）

有什么优点。使用查询 api、维护或其他东西时有什么区别吗？

Proposal 1:
--shared
------images
------pdf
------movies
--location1
------images
------pdf
------movies
--location2
------images
------pdf
------movies

Proposal 2: 
--pdf
-------shared
-------location1
-------location2
--images
--------shared
--------location1
--------location2
.. etc

原文

what is a proper way of organizing files in a wcm that is using JCR. Let's say the total file count is 100,000+ files and total file size is about 50-70GB.
Is it better to organize files by fie types ( and create sub directories to further group the files by some category)

What are the advantages. Does it make any difference while using query api, maintenance, or something.

Proposal 1:
--shared
------images
------pdf
------movies
--location1
------images
------pdf
------movies
--location2
------images
------pdf
------movies

Proposal 2: 
--pdf
-------shared
-------location1
-------location2
--images
--------shared
--------location1
--------location2
.. etc

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

街道布景 2024-09-11 10:55:22

看看这个：David 的模型：内容建模指南

一些亮点：

数据优先，结构稍后。或许。
推动内容层次结构，不要让它发生。
工作区用于clone()、merge() 和update()。
小心同名兄弟姐妹。
参考文献被认为是有害的。
文件就是文件就是文件。
ID是邪恶的。

回复收藏 0 原文

假扮的天使 2024-09-11 10:55:22

无论您做什么，请确保在任何给定节点下最终不会出现超过 1000 个子节点。
就像在任何（真实的）文件系统中一样，当您想要列出其中包含大量文件/子文件夹的文件夹时，可能需要一些时间。
默认情况下，Jackrabbit 2.x 现在将对用户空间进行哈希处理。
即：

/users/s/sa/sandra
/users/s/si/simong
...

我个人会支持你的第一个建议，因为它更有意义。
我们有一个 Web 应用程序，所有用户都可以在 JCR 中上传/删除/修改他们的文件，并这样做：

/_users/s/si/simon/public
/_users/s/si/simon/public/My Pictures
/_users/s/si/simon/public/My Pictures/2010/06/Trip to the US
/_users/s/si/simon/public/My Pictures/2010/06/Trip to the US/DC1001.jpg
/_users/s/si/simon/private/account_details.txt
...

我们大致遵循类 UNIX 系统中主文件夹的完成方式。
我们试图（合理地）把所有能做的事情混在一起。例如，像用户空间 (/s/si/simong) 一样，还有消息之类的东西：

/_users/s/si/simong/messages/2009/12/25/ab34ed87dee
/_users/s/si/simong/messages/2010/03/12/e4f1de3cd48
...

但是，单个用户在给定文件夹中的子文件不得超过 1000 个（不过我们确实警告他们。）
这样做还可以给您带来执行访问控制的好处。
即：~/private 下的所有内容只能由当前用户读写，~/public 则每个人都可以读取。

Whatever you do, make sure you don't end up with more than a 1000 child nodes under any given node.
Just as in any (real) file system, when you want to list a folder with a lot of files/subfolders in it, it can take some time.
By default Jackrabbit 2.x will now hash up the user space.
ie:

/users/s/sa/sandra
/users/s/si/simong
...

I would personally go for your first proposal as it makes more sense.
We have a webapp where all our users can upload/delete/modify their files in JCR and did it this way:

/_users/s/si/simon/public
/_users/s/si/simon/public/My Pictures
/_users/s/si/simon/public/My Pictures/2010/06/Trip to the US
/_users/s/si/simon/public/My Pictures/2010/06/Trip to the US/DC1001.jpg
/_users/s/si/simon/private/account_details.txt
...

We're loosely following the way home folders are done in UNIX-like systems.
We try to hash up all the things we (reasonably) can. Like the for example the user space (/s/si/simong) but also things like messages:

/_users/s/si/simong/messages/2009/12/25/ab34ed87dee
/_users/s/si/simong/messages/2010/03/12/e4f1de3cd48
...

However it's up to the individual user to not have more then 1000 child files in a given folder (we do warn them though.)
Doing it this way also gives you a nice benefit of exercising Access Control.
ie: everthing under ~/private is only read- and writeable by the current user, ~/public is readable by everybody.

回复收藏 0 原文

~没有更多了~