For security reasons, it is also best practise to avoid problems caused by IE's Content Sniffing which can allow attackers to upload JavaScript inside image files, which might get executed in the context of your site. So you might want to transform the images (crop/resize them) somehow before storing them to prevent this sort of attack. This answer has some other ideas.
嗯，我有一个类似的项目，用户将文件上传到服务器上。 在我看来，选项 a) 是最好的解决方案，因为它更灵活。 您必须做的是将图像存储在按子目录分类的受保护文件夹中。 主目录必须由管理员设置，因为内容不得运行脚本（非常重要）和（读、写）保护，以免在 http 请求中访问。
我希望这可以帮助你。
Well, I have a similar project where users upload files onto the server. Under my point of view, option a) is the best solution due to it's more flexible. What you must do is storing images in a protected folder classified by subdirectories. The main directory must be set up by the administrator as the content must no run scripts (very important) and (read, write) protected for not be accesible in http request.
If they are small files that will not need to be edited then option B is not a bad option. I prefer this to writing logic to store files and deal with crazy directory structure issues. Having a lot of files in one directory is bad. emkay?
If the files are large or require constant editing, especially from programs like office, then option A is your best bet.
For most cases, it's a matter of preference, but if you go option A, just make re the directories don't have too many files in them. If you choose option B, then make the table with the BLOBed data be in it's own database and/or file group. This will help with maintenance, especially backups/restores. Your regular data is probably fairly small, while your image data will be huge over time.
It depends on your requirements, specially volume, users and frequency of search. But, for small or medium office, the best option is to use an application like Apple Photos or Adobe Lighroom. They are specialized to store, catalog, index, and organize this kind of resource. But, for large organizations, with strong requirements of storage and high number of users, it is recommend instantiate an Content Management plataform with a Digital Asset Management, like Nuxeo or Alfresco; both offers very good resources do manage very large volumes of data with simplified methods to retrive them. And, very important: there is an free (open source) option for both platforms.
I generally store files on the file-system, since that's what its there for, though there are exceptions. For files, the file-system is the most flexible and performant solution (usually).
There are a few problems with storing files on a database - files are generally much larger than your average row - result-sets containing many large files will consume a lot of memory. Also, if you use a storage engine that employs table-locks for writes (ISAM for example), your files table might be locked often depending on the size / rate of files you are storing there.
Regarding security - I usually store the files in a directory that is outside of the document root (not accessible through an http request) and serve them through a script that checks for the proper authorization first.
The only benefit for the option B is having all the data in one system, yet it's a false benefit! You may argue that your code is also a form of data, and therefore also can be stored in database - how would you like it?
Unless you have some unique case:
Business logic belongs in code.
Structured data belongs in database (relational or non-relational).
Bulk data belongs in storage (filesystem or other).
It is not necessary to use filesystem to keep files. Instead you may use cloud storage (such as Amazon S3) or Infrastructure-as-a-service on top of it (such as Uploadcare):
I know this is an old post. But many visitors to this page are getting nothing related to the question. Especially for a newbie.
How to upload and store images or files in our website:
For a static website there maybe no problem since the file storage for some share hostings are still adequate. The problem comes from a dynamic website when it gets bigger. Bigger database can be handled, but bigger file quantities, such as images, becomes a problem. There are two types of images in a website:
Images that come from the administrator in a dynamic blog. Usually, these images have been optimized before upload.
Images from users. In case users are allowed to upload images such as avatars, or users can create blog content and input some images from text editor. In this kind of images it is difficult to predict the size. Users can upload big images just for small content resizing the view size but not the actual image size.
By ignoring item no. 1 above, quick solution for item no. 2 can be temporary solved by the following tips if we don't have image optimizer functionality in our website :
Do not allow users to directly upload from text editors by redirecting them to an image gallery. On this page users must upload files in advance before they can embedded in the content. This method is called File Manager.
Use a crop image function for users to upload images. This will limit the image size, even for users who upload very big files. The final image is the result of the cropped image. We can define the size in server side and accept only for example 500Kb or lower.
Now, that is only temporary. For a final solution, the question is repeated :
How to handle a big images storage?
Resize or change the extension.
How a big or medium website or e-commerce handle the file storage for their images?
What can we do then :
Migrate from share hosting VPS. Not enough? Then upgrade to Dedicated one.
Create your own server for file storage. Google how to do it. This is not as difficult as you think. Some people do it for their website.
The easy way is use a CDN file storage service.
Okay, 1 and 2 is little bit expensive. But not 3. I think is the best solution.
Some CDN services allow you to store as many web files as you want.
Question, "how to upload files to CDN from our website?"
Don't worry, once you register, usually free, you will get guidance how to upload files and get their link from/to your website. You will get an API and more. It's easy.
Some providers give us a free service for 14 days with limited storage and bandwidth. But that will be okay for starting point. The only problem is because 'people never try'.
编辑： 2017 年的一个简短说明，在 SQL Server 的最新版本中，有用于处理大量 BLOB 的新选项，这些选项应该可以避免我讨论的缺点。
编辑： 2020 年的快速说明，AWS/Azure/等中的 Blob 存储多年来也一直是一种选择。 这非常适合许多基于 Web 的项目，因为它很便宜，并且通常可以简化部署、扩展到多个服务器、必要时调试其他环境等方面的某些问题。
We have had clients insist on option B (database storage) a few times on a few different backends, and we always ended up going back to option A (filesystem storage) eventually.
Large BLOBs like that just have not been handled well enough even by SQL Server 2005, which is the latest one we tried it on.
Specifically, we saw serious bloat and I think maybe locking problems.
One other note: if you are using NTFS based storage (windows server, etc) you might consider finding a way around putting thousands and thousands of files in one directory. I am not sure why, but sometimes the file system does not cope well with that situation. If anyone knows more about this I would love to hear it.
But I always try to use subdirectories to break things up a bit. Creation date often works well for this:
Images/2008/12/17/.jpg
...This provides a decent level of separation, and also helps a bit during debugging. Explorer and FTP clients alike can choke a bit when there are truly huge directories.
EDIT: Just a quick note for 2017, in more recent versions of SQL Server, there are new options for handling lots of BLOBs that are supposed to avoid the drawbacks I discussed.
EDIT: Quick note for 2020, Blob Storage in AWS/Azure/etc has also been an option for years now. This is a great fit for many web-based projects since it's cheap and it can often simplify certain issues around deployment, scaling to multiple servers, debugging other environments when necessary, etc.
I have recently created a PHP/MySQL app which stores PDFs/Word files in a MySQL table (as big as 40MB per file so far).
Pros:
Uploaded files are replicated to backup server along with everything else, no separate backup strategy is needed (peace of mind).
Setting up the web server is slightly simpler because I don't need to have an uploads/ folder and tell all my applications where it is.
I get to use transactions for edits to improve data integrity - I don't have to worry about orphaned and missing files
Cons:
mysqldump now takes a looooong time because there is 500MB of file data in one of the tables.
Overall not very memory/cpu efficient when compared to filesystem
I'd call my implementation a success, it takes care of backup requirements and simplifies the layout of the project. The performance is fine for the 20-30 people who use the app.
Definitely resize the image, and check it's format if you can. There have been cases of malicious files being uploaded and served by unwitting hosts- for instance, the GIFAR vulnerability allowed you to hide a malicious java applet in a GIF file, which would then be able to read cookies in the current context and send them to another site for a cross-site scripting attack. Resizing the images usually prevents this, as it munges the embedded code. While this attack has been fixed by JVM patches, naively serving up binary files without scrubbing them opens you up to a whole range of vulnerabilities.
Remember, most virus scanners can only run against the filesystem- if you store your binaries in the DB, you won't be able to run a scanner against them very easily.
Store an uploaded image in temporary directory or memory.
Process that image before permanently storing it. 2.1. Color corrections 2.2. Compress 2.3. Create several copies based on image dimensions 2.4. Rename with .xl, .lg, .md, .sm etc. suffixes
Pack all processed image files (from a single file) inside a folder with folder name as id which will be stored in database for any row/document along with image file name (or may be random name as image name).
Create yyyy/mm/dpath folder if doesn't exist. For example 2016/08/21. Remember that path and store in database for same document and row.
Move image id folder to path folder. (Path folder may be located in /var/web-content folder.)
Flush memory buffer or delete temporary file.
When you need to access any image mentioned in a document, you have the path and id of the folder than contains images. For example /var/web-content/{{path}}/{{id}}/image-file-name.sm.jpg
This way if you have to delete all processed image files, just delete the folder and it's content recursively.
I use uploaded images on my website and I would definitely say option a).
One other thing I'd highly recommend is immediately changing the file name from what the user has named the photo, to something more manageable. For example something with the date and time to uniquely identify each picture.
It also helps to strip the user's file name of any strange characters to avoid future complications.
There's sort of a hybrid approach in SQL Server 2008 called the filestream datatype that was talked about on RunAs Radio #74, which is sort of like the best of both worlds. Most people don't have the 2008 otion, but if you do, this option looks pretty cool
With option B, you open a whole big can of whoop4ss when you marshall those bits from the database into something that can be displayed on a browser... Also, if the db is down, the images are not available.
I don't think that space is too much of an issue... Terabyte drives are a couple hundred bucks now.
We are implementing with option A because we don't have the time or resources to do option B.
For auto resizing, try imagemagick... it is used for many major open source content/photo management systems... and I believe that there are some .net extensions for it.
Absolutely, positively option A. Others have mentioned that databases generally don't deal well with BLOBs, whether they're designed to do so or not. Filesystems, on the other hand, live for this stuff. You have the option of using RAID striping, spreading images across multiple drives, even spreading them across geographically disparate servers.
Another advantage is your database backups/replication would be monstrous.
发布评论
评论（18）
选项 A。
加载图像后，您可以在保存之前验证格式并调整其大小。 http://www.codeproject.com 上有许多用于调整图像大小的 .Net 代码示例。 例如： http://www.codeproject.com/KB/cs/Photo_Resize.aspx
Option A.
Once the image is loaded you can verify the format and resize it before saving. There a number of .Net code samples to resize images on http://www.codeproject.com. For instance: http://www.codeproject.com/KB/cs/Photo_Resize.aspx
出于安全原因，最佳做法是避免 IE 内容嗅探 这可以允许攻击者在图像文件中上传 JavaScript，这可能会在您网站的上下文中执行。 因此，您可能希望在存储图像之前以某种方式转换图像（裁剪/调整图像大小）以防止此类攻击。 这个答案还有一些其他想法。
For security reasons, it is also best practise to avoid problems caused by IE's Content Sniffing which can allow attackers to upload JavaScript inside image files, which might get executed in the context of your site. So you might want to transform the images (crop/resize them) somehow before storing them to prevent this sort of attack. This answer has some other ideas.
嗯，我有一个类似的项目，用户将文件上传到服务器上。 在我看来，选项 a) 是最好的解决方案，因为它更灵活。 您必须做的是将图像存储在按子目录分类的受保护文件夹中。 主目录必须由管理员设置，因为内容不得运行脚本（非常重要）和（读、写）保护，以免在 http 请求中访问。
我希望这可以帮助你。
Well, I have a similar project where users upload files onto the server. Under my point of view, option a) is the best solution due to it's more flexible. What you must do is storing images in a protected folder classified by subdirectories. The main directory must be set up by the administrator as the content must no run scripts (very important) and (read, write) protected for not be accesible in http request.
I hope this helps you.
如果它们是不需要编辑的小文件，那么选项 B 不是一个坏选择。 与编写逻辑来存储文件和处理疯狂的目录结构问题相比，我更喜欢这样做。 在一个目录中放置大量文件是不好的。 恩凯？
如果文件很大或需要经常编辑，尤其是通过 Office 等程序进行编辑，那么选项 A 是您的最佳选择。
在大多数情况下，这是一个偏好问题，但如果您选择选项 A，只需重新设置目录中没有太多文件即可。 如果选择选项 B，则使包含 BLOB 数据的表位于其自己的数据库和/或文件组中。 这将有助于维护，尤其是备份/恢复。 您的常规数据可能相当小，而随着时间的推移，您的图像数据将变得巨大。
If they are small files that will not need to be edited then option B is not a bad option. I prefer this to writing logic to store files and deal with crazy directory structure issues. Having a lot of files in one directory is bad. emkay?
If the files are large or require constant editing, especially from programs like office, then option A is your best bet.
For most cases, it's a matter of preference, but if you go option A, just make re the directories don't have too many files in them. If you choose option B, then make the table with the BLOBed data be in it's own database and/or file group. This will help with maintenance, especially backups/restores. Your regular data is probably fairly small, while your image data will be huge over time.
这取决于您的要求，特别是搜索量、用户和搜索频率。 但是，对于中小型办公室，最好的选择是使用 Apple Photos 或 Adobe Lightroom 等应用程序。 它们专门用于存储、编目、索引和组织此类资源。 但是，对于存储要求较高且用户数量较多的大型组织，建议使用数字资产管理实例化内容管理平台，例如 Nuxeo 或 Alfresco； 两者都提供了非常好的资源，可以通过简化的检索方法来管理大量数据。 而且，非常重要的是：两个平台都有免费（开源）选项。
It depends on your requirements, specially volume, users and frequency of search. But, for small or medium office, the best option is to use an application like Apple Photos or Adobe Lighroom. They are specialized to store, catalog, index, and organize this kind of resource. But, for large organizations, with strong requirements of storage and high number of users, it is recommend instantiate an Content Management plataform with a Digital Asset Management, like Nuxeo or Alfresco; both offers very good resources do manage very large volumes of data with simplified methods to retrive them. And, very important: there is an free (open source) option for both platforms.
我通常将文件存储在文件系统上，因为这就是它的用途，尽管也有例外。 对于文件来说，文件系统（通常）是最灵活、最高性能的解决方案。
在数据库上存储文件存在一些问题 - 文件通常比平均行大得多 - 包含许多大文件的结果集将消耗大量内存。 此外，如果您使用的存储引擎采用表锁进行写入（例如 ISAM），您的文件表可能会经常被锁定，具体取决于您存储在那里的文件的大小/速率。
关于安全性 - 我通常将文件存储在文档根目录之外的目录中（无法通过 http 请求访问），并通过首先检查正确授权的脚本来提供它们。
I generally store files on the file-system, since that's what its there for, though there are exceptions. For files, the file-system is the most flexible and performant solution (usually).
There are a few problems with storing files on a database - files are generally much larger than your average row - result-sets containing many large files will consume a lot of memory. Also, if you use a storage engine that employs table-locks for writes (ISAM for example), your files table might be locked often depending on the size / rate of files you are storing there.
Regarding security - I usually store the files in a directory that is outside of the document root (not accessible through an http request) and serve them through a script that checks for the proper authorization first.
选项 B 的唯一好处是将所有数据集中在一个系统中，但这是一个错误的好处！ 您可能会说您的代码也是一种数据形式，因此也可以存储在数据库中 - 您希望如何？
除非你有一些特殊的情况：
不必使用文件系统来保存文件。 相反，您可以使用云存储（例如 Amazon S3）或基础设施即服务（例如Uploadcare）：
https ://uploadcare.com/upload-api-cloud-storage-and-cdn/
但是将文件存储在数据库中是一个坏主意。
The only benefit for the option B is having all the data in one system, yet it's a false benefit! You may argue that your code is also a form of data, and therefore also can be stored in database - how would you like it?
Unless you have some unique case:
It is not necessary to use filesystem to keep files. Instead you may use cloud storage (such as Amazon S3) or Infrastructure-as-a-service on top of it (such as Uploadcare):
https://uploadcare.com/upload-api-cloud-storage-and-cdn/
But storing files in the database is a bad idea.
我知道这是一个旧帖子。 但该页面的许多访问者没有得到与该问题相关的任何信息。 特别是对于新手来说。
如何在我们的网站中上传和存储图像或文件：
对于静态网站来说可能没有问题，因为某些共享主机的文件存储仍然足够。 当动态网站变大时，问题就出现了。 可以处理更大的数据库，但是更大的文件量（例如图像）就会成为问题。 网站中有两种类型的图像：
来自动态博客中的管理员的图像。 通常，这些图片在上传前已经过优化。
来自用户的图像。 如果允许用户上传头像等图像，或者用户可以创建博客内容并从文本编辑器输入一些图像。 在这种图像中很难预测其大小。 用户可以仅针对小内容上传大图像，调整视图大小，但不能调整实际图像大小。
通过忽略项目编号。 1 上面，项目号的快速解决方案。 如果我们的网站没有图像优化器功能，可以通过以下提示临时解决问题 2：
不允许用户通过将用户重定向到图像库来直接从文本编辑器上传。 在此页面上，用户必须提前上传文件，然后才能嵌入内容。 此方法称为文件管理器。
使用裁剪图片功能供用户上传图片。 这将限制图像大小，即使对于上传非常大文件的用户也是如此。 最终图像是裁剪图像的结果。 我们可以在服务器端定义大小并仅接受例如 500Kb 或更低。
现在，这只是暂时的。 对于最终的解决方案，重复的问题是：
那么我们能做什么：
从共享托管 VPS 迁移。 不够？ 然后升级到专用版。
创建您自己的文件存储服务器。 谷歌一下怎么做。 这并不像你想象的那么困难。 有些人为他们的网站这样做。
最简单的方法是使用 CDN 文件存储服务。
好吧，1和2有点贵。 但不是3。我认为是最好的解决方案。
某些 CDN 服务允许您存储任意数量的 Web 文件。
问题“如何从我们的网站将文件上传到 CDN？”
不用担心，注册后（通常是免费的），您将获得如何上传文件以及从您的网站获取文件链接的指导。 您将获得 API 等。 这很容易。
一些提供商为我们提供 14 天的免费服务，但存储和带宽有限。 但这对于起点来说是可以的。 唯一的问题是因为“人们从不尝试”。
希望对新手有所帮助。
I know this is an old post. But many visitors to this page are getting nothing related to the question. Especially for a newbie.
How to upload and store images or files in our website:
For a static website there maybe no problem since the file storage for some share hostings are still adequate. The problem comes from a dynamic website when it gets bigger. Bigger database can be handled, but bigger file quantities, such as images, becomes a problem. There are two types of images in a website:
Images that come from the administrator in a dynamic blog. Usually, these images have been optimized before upload.
Images from users. In case users are allowed to upload images such as avatars, or users can create blog content and input some images from text editor. In this kind of images it is difficult to predict the size. Users can upload big images just for small content resizing the view size but not the actual image size.
By ignoring item no. 1 above, quick solution for item no. 2 can be temporary solved by the following tips if we don't have image optimizer functionality in our website :
Do not allow users to directly upload from text editors by redirecting them to an image gallery. On this page users must upload files in advance before they can embedded in the content. This method is called File Manager.
Use a crop image function for users to upload images. This will limit the image size, even for users who upload very big files. The final image is the result of the cropped image. We can define the size in server side and accept only for example 500Kb or lower.
Now, that is only temporary. For a final solution, the question is repeated :
What can we do then :
Migrate from share hosting VPS. Not enough? Then upgrade to Dedicated one.
Create your own server for file storage. Google how to do it. This is not as difficult as you think. Some people do it for their website.
The easy way is use a CDN file storage service.
Okay, 1 and 2 is little bit expensive. But not 3. I think is the best solution.
Some CDN services allow you to store as many web files as you want.
Question, "how to upload files to CDN from our website?"
Don't worry, once you register, usually free, you will get guidance how to upload files and get their link from/to your website. You will get an API and more. It's easy.
Some providers give us a free service for 14 days with limited storage and bandwidth. But that will be okay for starting point. The only problem is because 'people never try'.
Hope it will help for newbie.
我们的客户在几个不同的后端上多次坚持使用选项 B（数据库存储），而我们最终总是回到选项 A（文件系统存储）。
即使 SQL Server 2005（这是我们尝试的最新版本）也不能很好地处理这样的大型 BLOB。
具体来说，我们看到了严重的膨胀，我认为可能是锁定问题。
另请注意：如果您使用基于 NTFS 的存储（Windows 服务器等），您可能会考虑找到一种将成千上万个文件放在一个目录中的方法。 我不知道为什么，但有时文件系统不能很好地应对这种情况。 如果有人对此了解更多，我很想听听。
但我总是尝试使用子目录来分解一些东西。 创建日期通常对此很有效：
Images/2008/12/17/.jpg
...这提供了相当程度的分离，并且在调试过程中也有一些帮助。 当存在真正巨大的目录时，资源管理器和 FTP 客户端都会有点卡住。
编辑： 2017 年的一个简短说明，在 SQL Server 的最新版本中，有用于处理大量 BLOB 的新选项，这些选项应该可以避免我讨论的缺点。
编辑： 2020 年的快速说明，AWS/Azure/等中的 Blob 存储多年来也一直是一种选择。 这非常适合许多基于 Web 的项目，因为它很便宜，并且通常可以简化部署、扩展到多个服务器、必要时调试其他环境等方面的某些问题。
We have had clients insist on option B (database storage) a few times on a few different backends, and we always ended up going back to option A (filesystem storage) eventually.
Large BLOBs like that just have not been handled well enough even by SQL Server 2005, which is the latest one we tried it on.
Specifically, we saw serious bloat and I think maybe locking problems.
One other note: if you are using NTFS based storage (windows server, etc) you might consider finding a way around putting thousands and thousands of files in one directory. I am not sure why, but sometimes the file system does not cope well with that situation. If anyone knows more about this I would love to hear it.
But I always try to use subdirectories to break things up a bit. Creation date often works well for this:
Images/2008/12/17/.jpg
...This provides a decent level of separation, and also helps a bit during debugging. Explorer and FTP clients alike can choke a bit when there are truly huge directories.
EDIT: Just a quick note for 2017, in more recent versions of SQL Server, there are new options for handling lots of BLOBs that are supposed to avoid the drawbacks I discussed.
EDIT: Quick note for 2020, Blob Storage in AWS/Azure/etc has also been an option for years now. This is a great fit for many web-based projects since it's cheap and it can often simplify certain issues around deployment, scaling to multiple servers, debugging other environments when necessary, etc.
我最近创建了一个 PHP/MySQL 应用程序，它将 PDF/Word 文件存储在 MySQL 表中（到目前为止每个文件有 40MB）。
优点：
缺点：
我认为我的实现是成功的，它满足了备份要求并简化了项目的布局。 对于 20-30 名使用该应用程序的人来说，性能还不错。
I have recently created a PHP/MySQL app which stores PDFs/Word files in a MySQL table (as big as 40MB per file so far).
Pros:
Cons:
I'd call my implementation a success, it takes care of backup requirements and simplifies the layout of the project. The performance is fine for the 20-30 people who use the app.
一定要调整图像的大小，并检查它的格式（如果可以的话）。 存在恶意文件被不知情的主机上传和提供服务的情况 - 例如，GIFAR 漏洞允许您在 GIF 文件中隐藏恶意 Java 小程序，然后该小程序能够读取当前上下文中的 cookie 并将其发送到另一个站点以进行跨站点脚本攻击。 调整图像大小通常可以防止这种情况发生，因为它会破坏嵌入的代码。 虽然这种攻击已通过 JVM 补丁修复，但天真地提供二进制文件而不清理它们会给您带来一系列漏洞。
请记住，大多数病毒扫描程序只能针对文件系统运行 - 如果您将二进制文件存储在数据库中，您将无法轻松地针对它们运行扫描程序。
Definitely resize the image, and check it's format if you can. There have been cases of malicious files being uploaded and served by unwitting hosts- for instance, the GIFAR vulnerability allowed you to hide a malicious java applet in a GIF file, which would then be able to read cookies in the current context and send them to another site for a cross-site scripting attack. Resizing the images usually prevents this, as it munges the embedded code. While this attack has been fixed by JVM patches, naively serving up binary files without scrubbing them opens you up to a whole range of vulnerabilities.
Remember, most virus scanners can only run against the filesystem- if you store your binaries in the DB, you won't be able to run a scanner against them very easily.
这基本上是我所做的。
2.1. 色彩校正
2.2. 压缩
2.3. 根据图像尺寸创建多个副本
2.4. 使用 .xl、.lg、.md、.sm 等后缀重命名
id，该文件夹将存储在数据库中以供任何行/文档以及图像文件名（或者可以是随机名称作为图像名称）。path文件夹（如果不存在）。 例如 2016 年 8 月 21 日。 记住该路径并存储在数据库中的相同文档和行。id文件夹移动到path文件夹。 （路径文件夹可能位于 /var/web-content 文件夹中。）当您需要访问文档中提到的任何图像时，您可以获得包含图像的文件夹的路径和 ID。 例如
/var/web-content/{{path}}/{{id}}/image-file-name.sm.jpg这样如果你必须删除所有处理过的图像文件，只需递归删除该文件夹及其内容。
This is basically I do.
2.1. Color corrections
2.2. Compress
2.3. Create several copies based on image dimensions
2.4. Rename with .xl, .lg, .md, .sm etc. suffixes
idwhich will be stored in database for any row/document along withimage file name(or may be random name as image name).pathfolder if doesn't exist. For example 2016/08/21. Remember that path and store in database for same document and row.idfolder topathfolder. (Path folder may be located in /var/web-content folder.)When you need to access any image mentioned in a document, you have the path and id of the folder than contains images. For example
/var/web-content/{{path}}/{{id}}/image-file-name.sm.jpgThis way if you have to delete all processed image files, just delete the folder and it's content recursively.
我在我的网站上使用上传的图像，我肯定会选择选项 a)。
我强烈建议的另一件事是立即将文件名从用户命名照片的名称更改为更易于管理的名称。 例如，带有日期和时间的内容可以唯一标识每张图片。
它还有助于删除用户文件名中的任何奇怪字符，以避免将来出现复杂情况。
I use uploaded images on my website and I would definitely say option a).
One other thing I'd highly recommend is immediately changing the file name from what the user has named the photo, to something more manageable. For example something with the date and time to uniquely identify each picture.
It also helps to strip the user's file name of any strange characters to avoid future complications.
SQL Server 2008 中有一种混合方法，称为 文件流数据类型，在 RunAs 上讨论过Radio #74，这有点像两全其美。 大多数人没有 2008 年选项，但如果你有，这个选项看起来很酷
There's sort of a hybrid approach in SQL Server 2008 called the filestream datatype that was talked about on RunAs Radio #74, which is sort of like the best of both worlds. Most people don't have the 2008 otion, but if you do, this option looks pretty cool
大多数实现都是选项 A。
使用选项 B，当您将数据库中的这些位编组到可以在浏览器上显示的内容时，您会打开一大堆 whoop4ss...此外，如果数据库关闭，图像也不会显示可用的。
我不认为空间是一个太大的问题...太字节驱动器现在是几百美元。
我们正在实施选项 A，因为我们没有时间或资源来执行选项 B。
Most implementations are option A.
With option B, you open a whole big can of whoop4ss when you marshall those bits from the database into something that can be displayed on a browser... Also, if the db is down, the images are not available.
I don't think that space is too much of an issue... Terabyte drives are a couple hundred bucks now.
We are implementing with option A because we don't have the time or resources to do option B.
对于自动调整大小，请尝试 imagemagick...它用于许多主要的开源内容/照片管理系统...并且我相信它有一些 .net 扩展。
For auto resizing, try imagemagick... it is used for many major open source content/photo management systems... and I believe that there are some .net extensions for it.
我们使用 A。我会将其放在共享驱动器上（除非您不打算运行多个服务器）。
如果到了这对你来说无法扩展的时候，那么你可以研究缓存机制。
We use A. I would put it on a shared drive (unless you don't plan on running more than one server).
If the time comes when this won't scale for you then you can investigate caching mechanisms.
绝对，肯定是选项 A。其他人提到数据库通常不能很好地处理 BLOB，无论它们是否被设计为这样做。 另一方面，文件系统就是为这些东西而存在的。 您可以选择使用 RAID 条带化、将映像分布在多个驱动器上，甚至将它们分布在地理位置不同的服务器上。
另一个优点是您的数据库备份/复制将是巨大的。
Absolutely, positively option A. Others have mentioned that databases generally don't deal well with BLOBs, whether they're designed to do so or not. Filesystems, on the other hand, live for this stuff. You have the option of using RAID striping, spreading images across multiple drives, even spreading them across geographically disparate servers.
Another advantage is your database backups/replication would be monstrous.