我的文档管理系统的要求是：
我决定将所有文档（和扫描的图像）作为 blob 存储在数据库中，到目前为止，我的体验非常棒，文档检索也非常快 - 它符合上面的所有标准，甚至还有一些额外的优势，例如自动存储文档及其相关实体，轻松快速地搜索内容，删除围绕文档打开和命名等的各种用户活动等。
我的问题是 - 在这个设计和实现中是否有任何严重的风险或我忽略的事情？
编辑说明：DB 是 PostgreSQL，可以很好地处理 BLOBS 并且可以很好地扩展。环境是多用户的。
当您的数据库变得越来越大时，备份将变得越来越困难。恢复包含超过 100 GB 数据的表的备份并不是一件让您高兴的事情。
另一件事是，随着数据集的增长，所有表管理功能都会变得越来越慢。
但这可以通过使您的数据表仅包含 2 个字段来克服：ID 和 BLOB。
检索数据（通过主键）可能只会在您备份数据集遇到困难很久之后才会成为问题。
我经常听到使用 blob 的主要缺点是，超过一定大小时，文件系统在存储和检索大文件方面效率更高。听起来您已经在您的要求列表中考虑到了这一点。
这里有一个很好的参考资料 (PDF)，涵盖了 blob 的优缺点。
根据我的经验，一些问题是：
速度与文件系统上的文件。
缓存。IMO Web 服务器将更好地缓存静态内容。数据库也会做得很好，但如果数据库还处理各种其他查询，不要指望那些大文档会长时间缓存。您基本上必须传输文件两次。一次从 DB 到 Web 服务器，然后从 Web 服务器到客户端。
内存限制。在我的上一份工作中，我们在数据库中有一个 40MB 的 PDF，并且在日志文件中不断出现 Java OutOfMemoryErrors。我们最终意识到，由于 Hibernate ORM 中的设置，整个 80MB PDF 不仅被读入堆中一次，而且被读入两次（如果对象是可变的，它会在内存中创建一个副本以供编辑）。将 PDF 流式传输回用户后，堆就被清理了，但是为了流式传输文档而一次从堆中取出 80MB 是一个巨大的打击。了解您的代码以及内存的使用方式！
您的 Web 服务器应该能够处理您的大部分安全问题，但是如果文档很小并且数据库还没有承受很大的负载，那么我认为将它们放在数据库中并没有什么大问题。
我刚刚开始研究用于 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 的一大弱点，您无法简单地附加任何类型的网络存储。