客户需要
document managment system,我正在构建有关此信息.

我知道sharepoint&露天,但在这种情况下,我正在评估从头开始构建它的必要信息,所以请不要建议使用任何这些(我们正在分别对它们进行评估,这是关于开发,而不是实现存在解).

这是requeriments：

>对我们当地政府特有的文件的法律管理有一个非常具体的要求,但除此之外：
>从最终用户的角度来看类似于谷歌文档的操作
>需要来自200个最终用户的商店信息(更新：真的是700个最终用户)
>主要是办公室文件,pdf,文字.我已经从这个二进制文件中提取纯文本了.
>没有wiki,没有门户创建,几乎没有工作流程,但很简单,只是文件的管理
>中央存储库,在整个公司内共享,与Active目录集成
>快速搜索
>透明桌面集成
> Web界面
>如果可能,多平台

所以,这就是我头脑中的事情：

>存储：我知道sharepoint在db中保存所有内容(Alfresco也是如此？).这是一场噩梦,恕我直言.我更喜欢将元数据放在数据库中,将文件放在磁盘上.

我想在这种情况下强制使用ZFS&利用他们的功能进行版本控制,快照和缩放.或者也许使用git作为存储后端(git可以正常工作吗？)

那么,在ZFS或任何常规文件系统中,我可以更多地了解如何处理大量文档？例如,如何将文件夹结构布局为易于管理&快速响应,轻松备份等

>元数据：我想在这里的常规数据库中,但是想知道是否有更多的功能来保存Lucene中的所有内容(我对Lucene有一些经验,但担心因为Lucene不能联合,严格？).

如果我使用搜索引擎作为元数据数据库,我可以节省一些工作(不需要第二遍索引),但常规数据库引擎更标准.

> Tech：我可能会在Django,PyLucene,Postgress中构建它,并为windows进行shell集成(我没有问题).

我将提供有关如何正确实施此解决方案的任何提示或信息.

最佳答案 我个人觉得“类似Google Docs”和“透明桌面集成”的要求有点模糊,恕我直言.但从这个问题来看,你更关注后端和文档存储,并且更多地考虑使用更开源的堆栈(与AD集成)？

无论如何,我个人使用KnowledgeTree作为我们的文档管理系统,它们的实现是所有文件都驻留在文件目录中,数据库将跟踪路径,相应的元数据,访问日志和版本信息.如果文档已经更新,他们基本上保留了同一文件的几个版本 – 我认为这是一个公平的想法,因为Microsoft Office文档主要是二进制文件(直到2003年).

您可能想要了解他们当前拥有多少文档以及他们希望每天流入此系统的文档数量. (或者从不同的角度来看,他们计划存储什么样的文档通常会给你提示你的服务器应该处理什么样的负载)

我的猜测是,你很可能会放弃使用本地文件系统和数据库存储元数据的设置,除非你确定系统每天都要处理大量文件(想象一下Flickr文件; )).