文档存储库-开源/设计模式

Question

我目前有几个web应用程序，提供文件上传和存储。我现在正在尝试创建一个中央文档管理服务，这些应用程序可以利用这个服务来存储和检索这些文档。目前，这些文档存储在磁盘上。文件名是Guid，其真正的文件名和数据类型存储在数据库中。

我是否遵循正确的方法，即我有一个数据库表来存储文档信息(名称、ContentType、CreatedDate、CreatedBy、SystemId等)，然后将文档存储在服务器本地文件系统上的文件夹中？

当我开始存储文档时，它们最初是数据库中的blobs。这我发现了一种不利的方法。我的数据库突然变得庞大，无法备份和恢复。要将文档分离到本地文件系统中，数据库现在要简单得多，我的备份策略也更容易。(备份数据库，从文件夹中备份文件)

有什么更明智的方法来做这件事我错过了吗？有什么开源项目，我可以利用它来改进我现在正在从头开始的新服务的设计吗？

Answer 1

这可能是最好的办法。

我唯一的警告是，您需要考虑文档文件的备份和错误恢复。

将两个副本存储在不同的磁盘上将给您与数据库中的blob大致相同的可恢复性。

Answer 2

根据企业的规模，随着内容管理系统需求的增加，您可能需要多个实例，因此您的体系结构的设计不仅应该针对文档id，还应该针对它所在的内容管理实例id。

然而，服务用户不应该担心这个路由细节。Architect是一种解决方案，在这种解决方案中，您可以使用某种规则引擎来确定用于存储文档的最佳实例。它可以基于某种统计数据收集或监视过程(可能是其他一些方案)，从而使用最有效的路由路径。

关键是，这个“路由系统”与内容管理系统实例和使用它们的客户端都是解耦的，允许您维护您的路由方案，而不会对用户或内容管理系统实例造成太大的干扰。

由于文档管理过程运行时间较长，您将更好地了解要为路由应用哪些规则，可能会更改规则引擎。

因此，guid将由路由系统创建，而不是内容管理系统(例如docid + ":“+ instanceid)。存储元数据的路由系统数据库应该有足够的信息，可以用于支持规则引擎的未来更改(使其更有效地工作)。