我的文档管理系统的要求是：
我决定将所有文档（和扫描的图像）作为 blob 存储在数据库中，到目前为止，我的体验非常棒，文档检索也非常快 - 它符合上面的所有标准，甚至还有几个其他优势，例如自动存储文档及其相关实体，轻松快速地搜索内容，消除围绕文档打开和命名等的各种用户活动等。
我的问题是 - 在这种设计和实施过程中，我是否忽略了任何严重的风险或事情？
编辑注意：DB 是 PostgreSQL，可以很好地处理 BLOBS 并且可以很好地扩展。环境是多用户的。
【问题讨论】：
标签： performance security document blob document-management
当您的数据库变得越来越大时，备份将变得越来越困难。 恢复包含超过 100 GB 数据的表的备份并不是一件让您高兴的事情。
另一件事是，随着数据集的增长，所有表管理功能都会变得越来越慢。
但这可以通过使您的数据表仅包含 2 个字段来克服：
ID 和 BLOB。
（通过主键）检索数据可能只会在您备份数据集遇到困难很久之后才会成为问题。
【讨论】：
我经常听到使用 blob 的主要缺点是，超过一定大小时，文件系统在存储和检索大文件方面效率更高。听起来您已经在您的要求列表中考虑到了这一点。
good reference (PDF) here 涵盖了 blob 的优缺点。
【讨论】：
根据我的经验，一些问题是：
速度与文件系统上的文件。
缓存。 IMO 网络服务器 缓存会做得更好 静态内容。数据库将做一个 也做得很好，但如果数据库也是 处理各种其他查询， 不要指望那些大文件 保持缓存很长时间。你 基本上必须转移 文件两次。一次从数据库到 Web 服务器，然后是 Web 服务器 客户。
内存限制。在我的上一份工作中，我们在数据库中有一个 40MB 的 PDF，并且在日志文件中不断出现 Java OutOfMemoryErrors。我们最终意识到，由于 Hibernate ORM 中的设置，整个 80MB PDF 不仅被读入堆中一次，而且被读入两次（如果对象是可变的，它会在内存中创建一个副本以供编辑）。将 PDF 流式传输回用户后，堆就被清理了，但是为了流式传输文档，一次从堆中取出 80MB 是一个很大的打击。了解您的代码以及内存的使用方式！
您的网络服务器应该能够处理您的大部分安全问题，但是如果文档很小并且数据库还没有承受很大的负载，那么我认为将它们放在数据库中并没有什么大问题.
【讨论】：
我刚刚开始研究用于 BLOB 的 SQL Server 2008 的 FILESTREAMing，并且遇到了一个巨大的限制 (IMO)——它只适用于集成安全性。如果您不使用 Windows 身份验证连接到数据库服务器，则无法读取/写入 BLOB。许多应用程序环境不能使用 Windows 身份验证。当然不是在异构环境中。
必须存在更好的存储 BLOB 的解决方案。最佳做法是什么？
【讨论】：
这取决于数据库类型。甲骨文还是 SQL Server？请注意一个缺点 - 恢复单个文档。
【讨论】：
根据我在 SQL Server 和 Oracle 中将内容文件存储为 blob 的经验，在小型数据库和少量登录用户的情况下都可以正常工作。 ECM 系统将它们分开，并为流媒体内容使用单独的服务。根据文件的大小，服务器资源可能会因同时检索大文件而受到影响。由于恢复时间和无法从存档中检索文档，包含大量文件的数据库存档会出现问题。
如果这些文件是公司记录，并且这是记录的权威副本，您可能会遇到合规性和保留管理问题，尤其是在您归档文件时。此外，搜索和版本控制可能会成为一个巨大的问题。
您可能希望使用某种 API 研究 ECM 系统，而不是重新发明轮子。
【讨论】：
抱歉 - 我提供的答案是基于 SQL Server，因此维护部分不合适。但文件 I/O 是在硬件级别完成的，任何数据库都会增加额外的处理步骤。
数据库在检索文档时会产生额外的开销。当文件在磁盘上时，您的速度仅与服务器上的 I/O 一样慢或快。您当然应该在数据库中管理您的元数据，但最终您需要文件的 UNC 并将用户指向 源头，让开。
从维护和管理的角度来看，在处理 MS SQL Server 时，您会限制自己使用 SAN。 Documentum 等解决方案采用不同的方法，在磁盘上进行简单存储，并允许您实施您认为合适的存储解决方案。
编辑
让我澄清一下我的说法 - 使用 SQL Server，当您超出盒子的物理存储容量时，您的选择有限。这实际上是 Sharepoint 的一大弱点，您无法简单地附加任何类型的网络存储。
【讨论】：