我正在编写一个允许用户将图像上传到服务器的应用程序。我预计每天大约20张图像都是jpeg，可能不会进行编辑/调整大小。 （这是另一个问题，如何在存储之前调整服务器端的图像大小，也许有人可以在评论中这样下载.NET资源）。 我现在想知道上传图片的最佳位置是什么。什么是存储上传图像，SQL数据库或磁盘文件系统的最佳地点？
将图像作为文件存储在文件系统中，并在具有该图像的确切路径的表中创建记录。或者，使用数据库服务器的“图像”或“二进制数据”数据类型将图像本身存储在表格中。
我看到两者的优点和缺点。 我喜欢a），因为我可以轻松地重新定位文件，只需更改表格条目。另一方面，我不喜欢在Web服务器上存储业务数据，并且我不想将Web服务器连接到任何其他持有业务数据的数据源（出于安全原因） 我喜欢b）因为所有的信息在一个地方，可以通过查询轻松访问。另一方面，数据库很快就会变得非常大。外包数据可能会更困难。
我通常将文件存储在文件系统上，因为这就是它的存在，虽然也有例外。对于文件，文件系统是最灵活和最高效的解决方案（通常）。
有与存储在数据库中的文件的几个问题 - 文件通常比一般的行大得多 - 包含许多大文件会消耗大量的内存结果集。另外，如果您使用使用表锁进行写入的存储引擎（例如，ISAM），则您的文件表可能会经常被锁定，具体取决于您在那里存储的文件的大小/速率。
关于安全 - 我通常将文件存储在目录是文档根目录（通过一个HTTP请求无法访问）之外，并且通过第一为适当的授权检查脚本为他们服务。
我们使用A.我会把它放在共享驱动器上（除非你不打算运行多个服务器）。
如果时间到了，这将不会为您调整，那么您可以调查缓存机制。
大多数的实现是选项A.
使用选B，你打开whoop4ss的一个整体的大罐，当你马歇尔从数据库中那些位到的东西，可以在浏览器上如果显示...此外，数据库关闭，图像不可用。
我不认为空间太大的问题的...... TB的硬盘是一对情侣，现在几百美元。
我们正在与方案A执行，因为我们没有足够的时间或资源做选项B.
的Flickr使用的文件系统 - 他们讨论原因here
绝对，肯定选择A.其他已经提到，数据库通常不能很好地处理BLOB，无论它们是否设计为这样做。另一方面，文件系统则适用于这些东西。您可以选择使用RAID分条，将图像传播到多个驱动器，甚至可以将它们分散到不同地理位置的服务器上。
另一个优点是您的数据库备份/复制将是可怕的。
对于自动调整大小，请尝试imagemagick ...它被用于许多主要的开源内容/照片管理系统......我相信它有一些.net扩展名。
我们有客户坚持在几个不同的后端几次选项B（数据库存储），我们总是最终返回到选项A（文件系统存储）。
即使通过SQL Server 2005，这是我们尝试过的最新的一个，这样的大型BLOB还没有得到很好的处理。
具体来说，我们看到了严重的膨胀，我认为可能会锁定问题。
另外一个注意事项：如果你使用基于NTFS的存储（Windows服务器等），你可能会考虑找到一种方法将成千上万的文件放在一个目录中。我不知道为什么，但有时文件系统不能很好地处理这种情况。如果有人对此有更多的了解，我很乐意听到它。
但我总是尝试使用子目录来分解一些东西。创建日期往往很适合这样的：
图片/ 2008/12/17/.jpg文件
...这提供分离的体面水平，调试当中也有点帮助。如果有真正庞大的目录，资源管理器和FTP客户端都会窒息。
编辑：只是2017年的一个快照，在更新版本的SQL Server中，有很多新的选项可用来处理大量的BLOB，这些BLOB应该避免我讨论的缺陷。
我在我的网站上使用上传的图片，我肯定会说选项a）。
我强烈建议的另一件事是立即将用户命名照片的文件名更改为更易于管理的内容。例如用日期和时间来唯一标识每张照片。
它也有助于去除用户的任何奇怪字符的文件名，以避免未来的复杂化。
绝对调整图像大小，如果可以，请检查它的格式。有一些恶意文件被不知情的主机上传并提供服务 - 例如，GIFAR漏洞使您可以将恶意Java小程序隐藏在GIF文件中，然后该文件可以读取当前上下文中的Cookie并将它们发送到另一个用于跨站点脚本攻击的站点。调整图像大小通常可以防止这种情况发生，因为它会传播嵌入的代码。虽然这种攻击已被JVM修补程序修复，但天真地提供二进制文件而没有对其进行清理会导致一系列的漏洞。
请记住，大多数病毒扫描程序只能运行在文件系统上 - 如果将二进制文件存储在数据库中，则无法轻松运行扫描程序。
我最近创建了一个PHP/MySQL应用程序，该应用程序将PDF/Word文件存储在MySQL表中（目前每个文件大小为40MB）。
优点：
缺点：
我会打电话给我的执行是成功的时候，它需要照顾的备份需求，简化了项目的布局。对于使用该应用程序的20-30人来说，表现很好。
选项A.
一旦加载图像，你可以验证格式和保存之前调整其大小。在http://www.codeproject.com有许多.Net代码示例来调整图像大小。例如：http://www.codeproject.com/KB/cs/Photo_Resize.aspx
如果它们是不需要编辑的小文件，则选项B不是一个错误的选项。我更喜欢编写逻辑来存储文件并处理疯狂的目录结构问题。有很多文件在一个目录中是坏的。 EMKAY？
如果文件很大或需要不断的编辑，尤其是像办公室这样的程序，那么选项A是最好的选择。
对于大多数情况下，这是一个优先选择的问题，但如果选择A，只需重新设置目录中没有太多文件。如果您选择选项B，那么使BLOBed数据表位于其自己的数据库和/或文件组中。这将有助于维护，特别是备份/恢复。您的常规数据可能相当小，而随着时间的推移，您的图像数据将为巨大的。
在SQL Server 2008中有一种称为filestream datatype的混合方法，在RunAs Radio #74上讨论过，它有点像两全其美。大多数人没有2008年的情绪，但如果你这样做，这个选项看起来很酷
出于安全原因，最好的做法是避免由IE's Content Sniffing造成的问题，这些问题可能允许攻击者上传JavaScript内部的图像文件，这可能会在您的网站上下文中执行。因此，您可能需要在存储图像之前以某种方式转换图像（裁剪/调整它们）以防止此类攻击。 This answer有一些其他的想法。
那么，我有一个类似的项目，用户上传文件到服务器上。在我看来，选项a）是最好的解决方案，因为它更加灵活。您必须做的是将图像存储在按子目录分类的受保护文件夹中。主目录必须由管理员设置，因为内容必须不受运行脚本（非常重要）和（读取，写入）保护，以便在http请求中不可访问。
我希望这可以帮助你。
选项B的唯一好处是在一个系统中拥有所有数据，但这是一个虚假的好处！您可能会争辩说，您的代码也是一种数据形式，因此也可以存储在数据库中 - 您希望如何？
除非你有一些独特的案例：
这是没有必要使用文件系统的文件保存。相反，你可以使用云存储（如Amazon S3）或基础设施作为一种服务在它的上面（如Uploadcare）：
https://uploadcare.com/upload-api-cloud-storage-and-cdn/
但在数据库中存储的文件是一个坏主意。
这基本上是我做的。
id将被一起存储在数据库中的任何行/文件内与image file name（或可能是随机名称作为图像名称）。path文件夹如果不存在。例如2016/08/21。记住该路径并将其存储在数据库中以获取相同的文档和行。id文件夹到path文件夹。 （路径文件夹可能位于/ var/web-content文件夹中。）当你需要访问一个文件中提及的任何图像，你比包含图像的文件夹的路径和ID。例如/var/web-content/{{path}}/{{id}}/image-file-name.sm.jpg
这种方式，如果你必须删除所有处理的图像文件，只需删除文件夹和它的内容递归。
这取决于您的要求，特别是音量，用户和搜索频率。但是，对于中小型办公室来说，最好的选择是使用Apple Photos或Adobe Lighroom等应用程序。它们专门用于存储，编目，索引和组织这种资源。但是，对于需要大量存储和大量用户的大型组织，建议使用Nuxeo或Alfresco等数字资产管理实例化内容管理平台;两者都提供了非常好的资源，可以用简化的方法来管理大量的数据，以便对其进行检索。而且，非常重要的是：这两个平台都有一个免费（开源）选项。
我知道这是一个旧帖子。但很多本页面的访问者没有得到任何关于这个问题的信息。特别是对于新手。
如何上传和存储图片或文件在我们的网站。
对于静态网站也许没有问题，因为某些共享主机的文件存储仍然充足。问题来自动态网站，当变大时。在数据库中可以处理更大，但是图像等文件中更大的问题。网站上有两种类型的图片：
图片来自动态博客的管理员。通常，这些图像在上传之前已经过优化，当然。
允许用户在用户的情况下上传图片，例如头像。或者用户可以创建博客内容并从文本编辑器中放置一些图像。这种图像很难预测尺寸。用户可以通过调整视图大小来调整小图片大小，但不能调整图片大小。
由于忽略了以上项目1号，为项目2号可以是暂时的通过以下提示解决，如果我们没有在我们的网站上的图像优化功能，快速的解决方案：
不要允许用户通过将文本重定向到图库直接从文本编辑器上传。在此页面上，用户必须提前上传文件，然后才能嵌入内容。这种方法被称为文件管理器。
为用户使用裁剪图像功能上传图像。这将限制图片大小，即使用户上传非常大的文件。最终图像是裁剪图像的结果。我们可以在服务器端定义大小，只接受例如500Kb或更低。
现在，这只是暂时的。对于最终解决方案，问题重复：
我们能做的则：从份额VPS主机
迁移。不够？然后通过升级到专用更高。
创建自己的文件存储服务器。谷歌搜索做到这一点。这并不像你想象的那么困难。有些人为他们的网站做。
简单的方法是使用CDN文件存储服务。
好吧，1和2有点贵。但没有3我认为是最好的解决方案。
某些CDN服务允许您根据需要存储您的网络文件。问题，如何从我们的网站上传文件到CDN？
不要担心，一旦你注册，通常是免费的，你会得到指导如何上传文件，并从/到您的网站得到他们的链接。你会得到一个API和更多。这很容易。
有些提供商为我们提供14天免费服务，存储和带宽有限。但是，这对起点是可以的。唯一的问题是因为“人们从不尝试”。
希望它会帮助新手。
这个问题在 – Draemon 2008-12-07 23:58:38
之前我没有找到它，在哪里？ – Tobias 2008-12-08 00:00:55
这里http://stackoverflow.com/questions/3748/storing-images-in-db-yea-or-nay – 2008-12-08 02:15:05