文档管理系统：使用什么作为存储后端（文档内容存储库）？
我想做一个文档管理系统（Ruby 界面）。
专业解决方案（Alfresco、Liferay 社交办公室等）使用什么来存储和版本控制文档？
我还能用什么？
要点：
- 存储空间优化（增量、压缩...）
- 版本控制
- 索引文档的能力（可以是外部的）
- 运行时备份的能力（实时热备份）
- 锁定？
- 大数据量的可扩展性
- 确保数据完整性（散列？）
- 权限
- 事务性
- 工作流程支持（可选）
加分点：
- KnowledgeTree 做吗？
- Liferay Social Office 是如何做到的（jcr？）？
- Alfresco 是如何做到的？
有关于这个问题的书吗？
I want to make a document management system (interface in Ruby).
What do profesional sollutions (Alfresco, Liferay social office, others) use for storing and versioning documents?
What else can I use?
Key points:
- storage space optimization (deltas, compression ...)
- versioning
- ability to index docs (can be external)
- ability to make backups at runtime (live hot-backup)
- locking?
- scalability on large data volume
- ensure data integrity (hashing?)
- permissions
- transactional
- Workflow support (optional)
Bonus points:
- how does KnowledgeTree do it?
- how does Liferay Social Office do it (jcr?) ?
- how does Alfresco do it ?
Any books on this issue ?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
alfresco 通常用作后端，它有一个很好的 REST API。如果您不喜欢所包含的 API，您还可以定义自己的集成 API。
alfresco is commonly used as the backend, it has a nice REST API. You can also define your own integration API if you don't like the included one.
你知道，我的第一直觉是只使用 Subversion。您需要外部索引，如果您想存储哈希值，您需要编写一些代码来自己完成，但其他一切都适合。
它配备了红宝石绑定，尽管我个人并不熟悉它们的质量。
Y'know, my first instinct would be to just use Subversion. You'll need external indexing, and if you want to store hashes you'll need to write some code to do it yourself, but everything else fits.
It ships with ruby bindings, though I'm not personally familiar with their quality.
我见过的大多数企业文档管理解决方案（Cimage、文档、LiveLink）绝对不关心#1。存储相对便宜，尤其是存储与处理（存储和检索）相比。它们主要依赖于基于文件系统的存储 - 可能具有名称抽象，例如
ShoppingList.doc可能变成20100909100101a.doc.rev1，数据库跟踪给定名称、存储的名称名称、修订版本和各种其他数据 {MIME 类型、标题和信息属性等}。通过不生成增量+压缩，您可以轻松地从任意数量的现有产品/算法中获得索引。使用这种方法版本控制也非常简单。根据您正在构建的大小和规模，您还可以将版本化文件存储在数据库中。
(S)FTP 或 CIFS 存储过程还允许您的软件在具有适度空间的应用程序服务器上运行，但将文件+历史记录存储在文件或某种类型的云服务器上 - 尽管这与基于文件系统的没有太大区别贮存。
Most of the enterprise document management solutions I've seen (Cimage, Documentum, LiveLink) definitely don't care about #1. Storage is relatively cheap, especially if it's storage vs processing (store and retreieve). They mostly rely on filesystem based storage - perhaps with name abstraction such that
ShoppingList.docperhaps becomes20100909100101a.doc.rev1, with a database tracking the given-name, the stored name, revisions, and various other data {MIME type, headers & properties etc}. By not generating deltas + compression you get indexing very easily from any number of existing products/agorithms. Versioning is also extremely simple with this approach.Depending on the size and scale you're building, you could also store versioned files within a database.
An (S)FTP or CIFS storage process would also allow your software to run on an app server with modest space, but store the files+history on a file or cloud server of some sort - although this isn't much different from filesystem based storage.