将文档作为Blob存储在数据库中 – 有什么缺点？
我的文件pipe理系统的要求是：
- 必须通过简单复制目录，文件等来防止盗窃
- 必须对传统的病毒感染（物理文件感染）
- 必须快速检索
- 对于随便的（目录）浏览用户来说，存储库是不可见的。
我决定将所有文档（和扫描的图像）作为斑点存储在数据库中，到目前为止，我的经验非常棒，文档检索也非常快速 – 它符合上述所有标准，甚至还有一些额外的优势，例如与相关实体一起自动保存文档，轻松快捷地浏览内容，在文档的打开和命名周围移除各种用户活动等。
我的问题是 – 在这个devise和实施中，是否有任何严重的风险或者我忽视的东西？
编辑注意：数据库是PostgreSQL，非常好地处理BLOBS和规模exception好。 环境是多用户。
当你的数据库变得越来越大，备份将变得越来越困难。 使用超过100 GB的数据恢复表的备份不是让你快乐的事情。
另一件事就是随着数据集的增长，所有的表pipe理function都变得越来越慢。
但是，这可以通过使您的数据表只包含2个字段来解决：ID和BLOB。
在备份数据集之后，检索数据（通过主键）很可能只会长久地成为问题。
我经常听说使用blob的主要缺点是，超过一定的大小，文件系统在存储和检索大文件方面效率更高。 这听起来像你已经采取了这个要求清单的帐户。
这里有一个很好的参考资料（PDF） ，涵盖了斑点的优缺点。
根据我的经验，有些问题是：
-
速度vs文件系统上的文件。
-
caching。 IMO的Web服务器将会更好地caching静态内容。 数据库也会做得很好，但是如果数据库也在处理各种其他的查询，不要指望那些大的文档长时间保持caching。 你基本上必须传输文件两次。 一旦从DB到Web服务器，再到Web服务器到客户端。
-
内存限制。 在我上一份工作中，我们在数据库中有一个40MB的PDF文件，并且在日志文件中不断收到Java OutOfMemoryErrors。 我们终于意识到，整个80MB的PDF不仅仅是一次读入堆中，TWICE也因为在Hibernate ORM中的一个设置（如果一个对象是可变的，它在内存中编辑一个副本）。 一旦PDFstream回给用户，堆已经被清理了，但是一次只能从文件堆中抽出80MB，这是一个很大的打击。 知道你的代码，以及如何使用内存！
你的web服务器应该能够处理你的大部分安全问题，但是如果文档很小，并且数据库还没有承受很大的负载，那么我真的不觉得把它们放在数据库中是个大问题。
我刚刚开始研究SQL Server 2008的BLOB的FILESTREAMing，并且已经运行了一个巨大的限制（IMO） – 它只适用于集成的安全性。 如果您不使用Windows身份validation连接到数据库服务器，则无法读取/写入BLOB。 许多应用程序环境不能使用Windows身份validation。 当然不是在异构的环境中。
存储BLOBs的更好的解决scheme必须存在。 什么是最佳实践？
本文涵盖了大部分问题。 如果您使用的是SQL Server 2008，请参阅Paul Randal 在此讨论的使用新的FILESTREAMtypes。
这取决于数据库types。 Oracle或SQLServer？ 请注意一个缺点 – 恢复单个文档。
对不起 – 我提供的答案是基于SQL Server，所以维护部分是不合适的。 但是文件I / O在硬件级完成，任何数据库都会添加额外的处理步骤。
数据库在检索文档时会带来额外的开销。 当文件在磁盘上时，你只能像服务器上的I / O一样慢或者快。 你当然应该在数据库中pipe理你的元数据，但最后你需要文件的UNC，并指向用户的源代码。
从维护和pipe理的angular度来看，在处理MS SQL Server时，您将自己局限于SAN。 像Documentum这样的解决scheme在磁盘上采用了简单存储的不同方法，并允许您按照自己的意愿实施存储解决scheme。
编辑
让我来澄清一下我的说法 – 在SQL Server中，如果超过了存储箱的物理存储容量，则select的选项有限。 这实际上是Sharepoint的一大弱点，你不能简单地附加任何types的networking存储。
从我曾经经历的将内容文件存储为blob的情况看，在SQL Server和Oracle中，对于小型数据库和login用户数量较less的情况都可以正常工作。 ECM系统将它们分开，并使用单独的服务来传输内容。 根据文件的大小，服务器资源可能会受到同时检索大文件的影响。 由于需要恢复时间以及无法从归档文件中检索文档，因此将大量文件归档到数据库会变得有问题。
如果这些文件是公司logging，并且这是logging的授权副本，则可能存在合规性和保留pipe理问题，特别是在归档文件时。 此外，search和版本控制可能成为一个巨大的问题前进。
你可能想用某种API调查一个ECM系统，而不是重新发明轮子。
