背景：
我们有一个早期实施的内部文档存储系统。出于某种原因，选择将数据库作为文档的存储机制。
我的问题是：
何为最佳文档存储实践？还有哪些选择？它们的优缺点是什么？答案不需要特定于技术或平台，这更像是一般最佳实践问题。
我的想法：
数据库不适合文档存储。文件系统或第三方文档管理系统可能更加合适。在数据库中存储文档是昂贵的，操作也很慢。这些是否是正确的假设？也许这是最好的方法，但我认为我们有更好的选择。使用Oracle BFILE（指向NAS或SAN上的文档链接）比BLOB / CLOB更好吗？
细节：
更新（从下面的问题）：
基于我的经验，我建议将它们保存在数据库中。我们把我们的两个系统都改成了这样。
将它们保存在数据库中意味着：
我们曾将文档存储在数据库之外。当文档数量很大时，这将成为一个问题。Linux中的普通目录占用一个块，通常为4K。我们有一个目录的大小为58MB，其中包含了这么多的文件（仅是一个平坦的目录，没有层次结构）。它有那么多的间接块。删除该目录花费了超过一个小时的时间。计算该目录中文件数量花费了几分钟的时间。情况非常糟糕。这是在ext3上发生的。
使用文件系统，你需要：
这真的很麻烦。对于任何大量文档的情况，我建议不要使用基于文件系统的方式，根据我的经验来看。
我更倾向于将文档保存在文件系统中，然后在数据库中存储与该文件相关的链接和元数据。
这种方法被证明比其他替代方案更方便、更易于维护，也更经济实惠。
我对将文件存储在数据库本身的最大担忧是管理备份和其他数据库维护操作的大小和复杂性。
缓解这种困难的一种策略（至少在MS SQL中）是创建单独的数据库分区，可能存储在不同的驱动器上。
然后将数据模式分离，使有关文件的元数据位于一个分区中，实际的BLOB文件位于另一个分区中。
这些分区可以根据不同的时间表进行备份，甚至可以单独恢复。
在数据库中存储文档的唯一限制是技术上的。
关系型数据库旨在成为企业使命关键数据的持久存储。当然，它能够执行该功能的效果因数据库和系统而异。但是，理想情况下，关系型数据库的ACID属性旨在将其作为所有企业数据的存储。文件系统、版本控制系统和其他本地存储系统可能具有特定优势，但它们并非专门设计用于企业数据存储。
如果您存储的文件属于企业数据 - 如果它们在整个企业中持续使用 - 那么将它们保存在数据库中是合理的。如果您在存储过程中遇到问题，也许DBA可以找到更好的解决方案。出于性能原因，您甚至可能不得不将它们移出数据库，但我认为出于最佳实践的原因，您不应将它们移出数据库。我曾经把图片存储为BLOBs在数据库中，但第一次批量操作这些图片时就后悔了。如果在文件系统中操作会更容易。而且，正如你所提到的，如果文件存储在文件系统中，检索文档的速度会更快。
我的简单观点是：文件系统应该存储文件，关系型数据库应该存储关系数据。
将二进制文件存储在文件系统中。创建一个ASP.NET应用程序来进行存储和检索操作。您可以在Web应用程序中使用高级功能（文档版本控制、多层安全等）。我认为这是文档管理行业的共识。
由于您的“文档数量急剧增长”，看起来这正在变成大规模的问题。您可能需要开始寻找第三方现成解决方案（例如http://kofax.com/capture/ - 我对此有丰富的经验！）来为您完成“肮脏的工作”。或者更好的选择是考虑使用SaaS服务，例如这些公司http://www.edocumentsolutionsllc.com/
:-)
如果您想要访问文件并进行编辑和重新保存，请将文档存储为 .doc 等文件。
如果您想要实际的历史副本，可以随时检索和再现，请将文档存储为 .pdf 或 .tiff 等文件。
请将有关文件的所有信息（例如日期、作者、位置）存储在数据库中。
我通常会将文档的核心信息和文件路径存储在数据库中，但从不存储文档本身。很少需要将整个文档存储在数据库中。
这样可以更灵活地使用这些文档。例如，想要使用分层备份存储和去重机制吗？可以尝试在 Oracle BLOBs 中实现。
