文档/图像数据库存储库设计问题

Question

问题：

我应该编写应用程序来直接访问数据库Image Repository还是编写一个中间件来处理文档请求。

背景：

我有一个自定义的Document Imaging和Workflow应用程序，目前存储大约1500万个文档/文档图像（90％+单页，第4组tiff，其余PDF，Word和Excel文档）。图像存储库是一个商业的第三方应用程序，非常昂贵，坦率地说有太多的开销。我只需要一个系统来存储和检索文档图像。

我正在考虑将映像直接转移到SQL Server 2005数据库中。索引信息非常有限 - 基本上是2个索引字段。这是一个人寿保险单管理系统，因此我使用策略编号和系统范围的唯一ID号索引图像。还有其他索引值，但它们与图像数据分开存储和维护。这些索引值使我能够查找单个图像检索的唯一id值。

数据库服务器是双四核Windows 2003机箱，其中SAN驱动器托管数据库文件。当前的映像存储库大小约为650GB。我没有做过任何测试，看看转换后的数据库有多大。我并不是真的在询问数据库设计 - 我正在与DBA合作。如果这改变了，我会回来的： - ）

目前要替换的系统显然是一个中间件应用程序，但它是一个非常重量级的系统，分布在3个Windows服务器上。如果我走这条路，它将是一个单一的服务器系统。

我主要担心的是可控性和性能 - 非常重视性能。我有大约100个用户，未来几年的使用量增长可能会很慢。 大多数用户主要是读取用户 - 他们不经常向系统添加图像。我们有一个处理扫描和以其他方式将图像添加到存储库的部门。我们还有一些其他应用程序接收文档（通过ftp），并在收到文件时自动将它们插入存储库，或者是完整的索引信息，或者是<！>“批次<！>”;用户评论和索引。

大多数（90％以上）的文件/图片非常小，<！> lt; 100K，可能<！> lt; 50K，所以我相信在数据库文件中存储图像将是最有效的，而不是获取SQL 2008并使用文件流。

Answer 1

通常情况下，可扩展性和性能最终会相互结合，从现在开始管理的六个月后回来并说<！>“应用程序X中的功能Y运行速度慢得令人无法接受，我们如何加快速度？” > QUOT;通常，答案是升级后端解决方案。当谈到升级后端时，它的扩展几乎总是比扩展硬件更便宜。

因此，长话短说，我建议构建一个专门处理来自用户应用程序的传入请求的中间件应用程序，然后将它们路由到适当的目标。这将从后端存储解决方案中充分抽象您的前端用户应用程序，以便在可伸缩性成为问题时，只需要更新中间件应用程序。

Answer 2

这很简单。将应用程序写入接口，使用某种工厂机制来提供该接口，并根据需要实现该接口。

一旦你对你的界面感到满意，那么应用程序（大部分）就会与实现隔离开来，无论是直接与数据库还是其他组件交谈。

在你的界面设计上稍微考虑一下，但做骨头愚蠢，<！>;它很简单，它可以在这里工作，现在可以正常工作<！>实现提供了未来验证系统的良好平衡，而不一定是过度设计它。

很容易说你在这个时刻甚至不需要一个接口，而只是一个你实例化的简单类。但是如果你的合同定义得很好（即接口或类签名），那么就可以保护你免受更改（比如重做后端实现）。如果您认为有必要，可以随后使用界面替换该类。

就可扩展性而言，测试它。然后你不仅知道你是否需要扩展，但也许你也需要扩展。 <！>“适用于100个用户，200个问题，如果我们达到150，我们可能会考虑再看一下后端，但现在好了。<！>

这是尽职调查和负责任的设计策略，恕我直言。

Answer 3

我同意gabriel1836。然而，额外的好处是，您可以暂时运行混合系统一段时间，因为您不会在一夜之间将1400万个文档从您的专有系统转换为本土系统。

另外，我强烈建议您将文档存储在数据库之外。将它们存储在文件系统（本地，SAN，NAS无关紧要）上，并存储指向数据库中文档的指针。

我很想知道您现在正在使用的文档管理系统。

另外，不要低估更换专有系统提供的捕获（扫描和导入）的工作量。