当您的数据库变得越来越大时，备份就会变得更加困难。还原一个包含超过100GB数据的表格并不是一件让人高兴的事情。
另一个问题是随着数据集的增长，所有的表管理功能都会变得越来越慢。
但这可以通过将数据表中仅包含两个字段来解决：ID和BLOB。
只有在备份数据集达到瓶颈后，通过主键检索数据才可能成为问题。
我经常听到使用BLOB的主要缺点是，在某些大小以上，文件系统比存储和检索大文件更有效率。根据您的需求清单，您似乎已经考虑到了这一点。
这里有一个PDF参考文献，涵盖了BLOB的优缺点。
根据我的经验，一些问题包括：
速度和将文件存储在文件系统上的取舍。
缓存。我认为Web服务器会更好地缓存静态内容。数据库也可以很好地处理，但是如果数据库还要处理各种其他查询，就不要指望那些大型文档能够长时间保留在缓存中。实际上您必须将文件传输两次：一次从数据库到Web服务器，然后从Web服务器传输到客户端。
内存限制。在我上一份工作中，我们在数据库中有一个40MB的PDF，并且在日志文件中不断收到Java OutOfMemoryErrors。我们最终意识到，由于Hibernate ORM中的一个设置（如果对象是可变的，则为编辑在内存中进行副本），整个80MB PDF不止一次地读入堆中。一旦将PDF流式传输回用户，堆就被清理了，但是一次性将80MB的数据从堆中读出以流式传输文档对性能影响很大。要了解您的代码以及如何使用内存！
您的Web服务器应该能够处理大部分安全问题，但是如果文档很小而且数据库没有承受大负载，那么在数据库中存储它们我认为没有大问题。
我刚开始研究SQL Server 2008的FILESTREAMing用于BLOBs，并发现一个巨大的限制（依我之见）--它只能与集成安全一起使用。如果您不使用Windows身份验证连接到DB服务器，则无法读取/写入BLOBs。许多应用程序环境无法使用Windows身份验证。在异构环境中肯定不行。
存在更好的存储BLOBs的解决方案。最佳实践是什么？
这取决于数据库类型。Oracle还是SQLServer？请注意一个缺点 - 恢复单个文档。
根据我的经验，在SQL Server和Oracle中将内容文件存储为blob，对于小型数据库和低数量的登录用户来说可以正常运作。ECM系统分离它们并使用单独的服务来流式传输内容。根据文件的大小，同时检索大文件可能会影响服务器资源。具有大量文件的数据库的归档由于恢复时间和无法从存档中检索文档而变得棘手。
如果这些文件是公司记录，并且这是记录的权威副本，您可能会遇到合规性和保留管理问题，特别是如果您存档这些文件。此外，搜索和版本控制可能成为未来的重大问题。
您可能需要调查一下带有API的ECM系统，而不是重新发明轮子。
抱歉 - 我提供的答案基于SQL Server，因此维护部分不适用。但是文件I/O是在硬件级别完成的，任何数据库都会增加额外的处理步骤。
检索文档时，数据库将会施加额外的开销。当文件在磁盘上时，您只能像服务器上的I/O一样快或慢。您确实应该在数据库中管理您的元数据，但最终您需要文件的UNC并指向用户到源文件，然后离开。
从维护和管理的角度来看，处理MS SQL Server时，您将限制自己使用SAN。像Documentum这样的解决方案采用了不同的方法，在磁盘上进行简单存储，并允许您根据需要实现存储解决方案。
编辑
让我澄清一下我的说法 - 在超出盒子的物理存储容量时，使用SQL Server时您的选择有限。这实际上是Sharepoint的一个重大弱点之一，即您无法简单地连接任何类型的网络存储。
