因为我已经被告知不要存储数据库，或任何与此有关的大BLOB上的图像的年龄。虽然我可以理解为什么数据库不是/没有效率，因为我从来不明白为什么他们不能。如果我可以把文件放在某个地方并引用它，为什么数据库引擎不能做同样的事情。我很高兴Damien Katz在最近Stack Overflow播客中提到它，并且Joel Spolsky和Jeff Atwood至少默默地同意了这一点。
我一直在阅读微软SQL Server 2008应该能够有效处理BLOB的提示，这是真的吗？如果是这样，那么在什么地方阻止我们将图像存储在那里并摆脱一个问题呢？我能想到的一件事是，虽然图像可以很快地由静态Web服务器提供，但如果它位于某个文件的某个位置，则当它位于数据库中时，它必须从数据库传输到Web服务器应用程序（这可能比静态Web服务器），然后它被服务。不应该缓存帮助/解决最后一个问题？
是的，的确，SQL Server 2008只是实现了一个像你提到的功能，它被称为文件流。如果你确定你只想为你的应用使用SQL Server（或者愿意为性能付出代价或者在新的开发之上开发一个类似的层），那么在数据库中存储blob确实是一个很好的论点。 DB服务器）。尽管我预计类似的图层会在不存在于不同的数据库服务器时开始出现。
像往常一样，真正的好处取决于特定的场景。如果您将提供大量相对静态的大文件，那么考虑到性能/可管理性组合，此场景加缓存可能是最佳选择。
This white paper描述了SQL Server 2008的FILESTREAM功能，该功能允许使用SQL Server 2008和NTFS文件系统的组合存储和有效访问BLOB数据。它涵盖了BLOB存储的选择，为使用FILESTREAM数据配置Windows和SQL Server，将FILESTREAM与其他功能组合的注意事项以及分区和性能等实施细节。
这是一个很好的答案，我想我应该删除我的，锁定你进入NTFS和复杂的实现细节非常痛苦，但我可以想到一些可能需要它的解决方案。 – 2009-07-01 22:29:11
SQL Server中有一些选项可用于管理存储大型数据块的位置，这些数据块自SQL2005起至今一直存在，因此我不知道为什么无法存储大型BLOB数据。例如，MOSS会将您上传的所有文档存储在SQL数据库中。
当然有一些性能影响，就像任何事情一样，所以你应该注意，如果你不需要它，不要检索blob，也不要将它包含在索引等中。
文件流在2008年是新的。文件流确实对普通的varbinary产生了巨大的影响，请检查我的答案中的链接。 – 2009-07-01 22:28:53
是的，他们会是最好的。但MOSS（Microsoft Office Sharepoint Server）安装在SQL 2005上，它将文档存储在数据库中，因此在2005年必须有功能。 – 2009-07-02 00:09:50
只因为你可以做点什么并不意味着你应该这样做。
如果你关心效率，你仍然很可能不想为任何足够大规模的文件服务做到这一点。
另外它看起来像这个话题已深入讨论......
之一古典原因对在数据库中存储BLOB谨慎的是，数据将被存储和事务控制，这意味着该DBMS需要确保它可以回滚变化下编辑（改变），和在崩溃后恢复更改。这通常是通过对事务日志主题的一些变化来完成的。如果DBMS要将更改记录在2 GB的blob中，那么它必须有一种方法来确定发生了什么变化。这可能是简单的（前图像和后图像）或更复杂的（某种二进制增量操作），这在计算上更昂贵。即便如此，有时最终的结果将是千兆字节的数据通过日志存储。这会伤害系统性能。有多种方法可以限制更改的影响 - 减少流经日志的数据量 - 但有一些折衷。
在数据库中存储文件名的代价是数据库管理系统在文件更改时没有控制权（一般情况下），因此数据的再现性受到损害;你不能保证DBMS之外的某些东西没有改变数据。 （这个论点有一个非常普遍的版本 - 你不能确定有人一般没有篡改数据库存储文件，但我指的是在数据库中存储一个文件名，引用一个不受DBMS。由DBMS控制的文件受到无特权的偶然更改的保护）。
新的SQL Server功能听起来很有趣。我还没有探究它的作用，所以我不能评论它避免或限制上面提到的问题的程度。
我会尽量分解你的问题，并尽可能地处理你的各个部分。
SQL Server 2008和文件流类型 - 上面Vinko的回答是到目前为止我见过的最好的一个。文件流类型是SQL Server 2008是您正在寻找的。 Filestream在版本1中，所以如果对于企业应用程序，我仍然不推荐使用它，但仍有一些原因。作为一个例子，我的回忆是，你不能跨多个Windows UNC路径拆分底层物理文件的存储。迟早会成为企业应用的一个非常严重的限制。
在数据库中存储文件 - 在这个宏伟的方案中，Damien Katz的原始方向是正确的。大多数大型企业内容管理（ECM）播放器将文件存储在RDBMS中的文件系统和元数据上。如果你做得更大，查看亚马逊的S3服务，你就会看到带有非关系数据库后端的物理文件。除非你在数十亿的存储空间中测量你的文件，否则我不会推荐走这条路线并自己动手。
有关数据库中文件的更多详细信息 - 乍一看，很多事情都代表着数据库中的文件。一个是简单性，二是交易完整性。由于Windows文件系统不能在事务中入伍，因此需要在数据库和文件系统中发生的写入需要内置事务补偿逻辑。直到我与DBA交谈之前，我并没有真正看到故事的另一面。他们通常不喜欢混合的业务数据和blob（备份变得痛苦），所以除非你有一个单独的专用于文件存储的数据库，否则这个选项通常不会吸引DBA。你说得对，数据库会更快，所有其他的事情都是平等的。不知道你的应用程序的用例，我不能多说缓存选项。可以这么说，在许多企业应用程序中，文档上的缓存命中率太低以至于无法缓存它们。
希望这会有所帮助。
相关：http://stackoverflow.com/questions/3748/storing-images-in-db-yea-or-nay – 2009-07-01 22:20:35
类似：http://stackoverflow.com/questions/815626/to-do-or不在数据库中存储图像 还有很多其他的。 – 2009-07-01 22:35:04