可能重复：文件-是否在数据库中？
我想知道是否有充分的理由仍然需要在数据库中使用blob字段。几年前，我与一个装有一堆图像的数据库一起工作，该数据库非常慢，我看不出任何将图像保留在数据库中的充分理由，所以我取出了图像并存储了文件名相反。
这是明智之举吗？你会代替我做什么？
#1 楼
从其他答案中可以看出，这是一个很大的“取决于”。其他一些因素可能是，如果您要为托管付费，它们是否对文件存储或数据库存储收取更多费用。文件存储通常比较便宜，尤其是对于云服务而言。如果您是自托管的并且使用SQL Server，即将发布的版本（代号Denali）将扩展FILESTREAM，以允许通过TSQL和文件系统进行访问。它还将确保它们保持同步。您可以从任何一侧进行访问，更新，删除，这将使所有内容保持井井有条。
评论
和SQL服务器2K8呢？
– Garik
2011年1月20日在20:09
在2008＆R2中有FILESTREAM版本，但是如果通过文件共享进行修改，文件可能会不同步。 Denali解决了这个问题。还不是RTM。
–埃里克·汉弗莱-lotahelp
2011年1月20日在20:13
+1指出今天的FILESTREAM问题。我对他们在Denali所做的事情感兴趣，但老实说-这个想法仍然让我感到恐惧！ ;）
– AndrewSQL
2011年1月21日，下午4:05
为Denali功能（dba.stackexchange.com/q/401/81）+1，添加了参考。
– Garik
2011年1月21日7:05
#2 楼
使用BLOB的原因很简单，就是易于管理-您只有一种方法可以备份和还原数据库，可以轻松进行增量备份，映像及其存储在数据库表中的元数据不同步的风险为零。 ，您还具有一个编程界面来运行查询或加载/保存图像，因此您无需授予远程客户端文件系统访问权限，并且您知道相同的GRANT将应用于图像及其相关数据。另外，您还有一种存储管理方法（例如，在Oracle中，您可以将所有内容放在ASM上，并使用Oracle作为您的LVM进行所有操作）。另一个应用程序是将关系数据与序列化对象混合在一起（BLOB可以是任何二进制，而不必是图像）。或者，您可以对关系数据和BLOB中的字节x-y运行查询，例如，可能是文件头。实际上，应用是无止境的。
如果访问BLOB的速度比访问文件系统的速度慢，则很可能是您的数据库配置错误。
评论
因此，我们将数据库更改为blob。这些图像是客户的图像。它们与数据库中的数据直接相关，并将它们组合在一起使备份更加容易。
–SchwartzE
2011年1月20日19:28
#3 楼
我不使用Blob，主要是从备份和还原的角度来看，因为我不希望Blob数据减慢备份速度。我没有存储完整的URL。 。我仅将文件路径存储在特定点以下，并构建路径，因为人们和程序可以通过多种方式访问我的文件（FTP，HTTP，本地目录，NFS挂载目录）。
...当然，我处理的图像可能比大多数人还要多。...我的一个数据集每天可获得约700GB的图像（压缩）。但是，即使是那些图像的缩略图，我仍然在外部存储。
评论
我不明白你的理由。这是否意味着您根本不备份图像？如果备份它们，那肯定也会减慢某些速度。
–RenéNyffenegger
2011年1月20日19:37
@René：备份的文件位于完全不同的存储（SAN）中。我们还有一些可以在不同类别的存储上重新生成的内容（例如，缩略图），以及其他数据，这些数据是我们执行其他任务的镜像站点，因此，如果发生灾难，我们可以让他们为我们提供新副本。 （我的意思是当我说“运送”时，我的意思是当人们需要大量数据时，我们会邮寄一堆4-6磁盘RAID磁盘阵列）
–乔
2011年1月20日在20:06
@Gaius：嗯...你意识到增量仍然需要吃饱，对吗？我的意思是，您不想将1400个增量应用于一个已有4年历史的数据库。就我而言，数据库小于图像大小的1/1000。另外，图像的存储类型与数据库的存储类型不同，并且图像备份（在备份时）的存储类型与数据库备份的存储类型不同。他们还有不同的保留规则，等等。
–乔
2011年1月20日21:35
+1，因为我也在“不要将文件Blob放在数据库中”阵营。这太麻烦了，很快就无法处理，而且如果不花钱解决问题就无法很好地扩展。
– AndrewSQL
2011年1月21日，下午4:09
@AndrewSQL：实际上，扩展也是问题的重要组成部分-Web服务器（和FTP服务器）是水平扩展的，并分别进行了调整。
–乔
2011年1月21日14:04
#4 楼
我非常喜欢将图像的“参考”副本存储在数据库中-从可管理性/灾难恢复的角度来看，这确实是飞行的方式。现在，您仍然可以对于大多数应用程序来说，有很多事情可以将图像从文件系统中提供服务，因此您不会对数据库服务器本身施加太大的压力来执行它实际上不希望做的事情。
评论
我完全同意这种做法。在我昂贵的数据库服务器上进行参考副本，并在相对便宜的Web服务器或任何客户端上缓存映像，以最大限度地提高性能，并让数据库服务器仅提供映像以维护一个或多个缓存。
– MartinSjöberg
2011年9月8日在12:26
#5 楼
如果您使用的是Linux，则将映像存储在文件系统中而不是数据库中会显着提高性能，请参阅Brad Ediger的书Advanced Rails的摘录。评论
感谢您的链接-我还没有看到过'X-Sendfile'方法...我一直使用重定向，但是我有几个CGI在其中可能有用。
–乔
2011年1月21日在22:07
#6 楼
我不太喜欢在数据库中存储图像。在一个只有几个用户的小型应用中，这似乎是一个简单的解决方案，但是随着您开始扩展，它会使事情变得更加困难。我的首选是开始将图像存储在Web服务器，但将路径保持在易于访问的配置中，以便在需要时可以将它们快速移至他们自己的专用优化图像服务器。稍后，我可能想以相同的方式将它们移动到其他位置（例如S3或Akamai）。如果我不得不更改原本希望从数据库中读取代码的代码，那么所有这些操作将变得更加复杂。
#7 楼
这是一个聪明的举动吗？
如果这不是一个聪明的举动，则取决于您的具体情况：
如果文件位置直接影响任何url结构，或者如果您将完整的文件地址存储在数据库中（错误），我可以说这是一个错误的举动，因为如果有人移动或重命名某些目录，您将遇到麻烦。
但是，但是如果您以某种方式构建应用程序，则只需指向文件目录，并且文件访问逻辑是动态的，则出于以下原因，您明智地采取了行动：
通过数据库存储，如果每个请求需要提供大量图像，则会增加应用程序的响应时间，因为文件将被同步发送到网络。
/>另外，您还将向服务器添加更多处理。
文件存储通常比数据库存储便宜。
使用文件存储（除非对图像访问有限制：
用户可以访问给定的一组图像），无需进行任何处理即可访问图像或任何其他类型的文件。
利用数据库存储，无法使用FTP访问您的文件（漂亮很明显，但是请记住）。
数据库文件存储将减慢和/或使数据库混乱
定期备份。
我将如何处理地点？
除非出现相反的主导因素，否则我将保留该决定。
希望有所帮助。
评论
以重复方式结束，以便将讨论限制在以后的一篇文章中。不合并，因为此处的上下文很好。将来如果需要合并，我们可以。