平台并不像理论那么重要。作为记录，它是 ASP.NET（3.5 SP1 上的 C#）、SQL Server 2005。为了论证，我有无限的空间（文件系统和数据库）和无限的带宽。
我正在开发一个项目，该项目将允许多个用户上传他们自己的图像，这些图像可以由该用户管理并由所有用户查看。我正在尝试确定最好的存储机制是什么。我的想法是，我希望避免将它们直接存储在数据库中，尽管我可以看到存储有关图像的信息。
我看到的是用户会上传图片。服务器将为图像创建一个唯一的名称，将其存储到文件系统中，并将有关该图像的关系数据存储在数据库中（即，当它被上传时，与用户的关联，对标题的引用等）。将这些存储在磁盘上是未来能够迁移到 CDN 的一步。
有没有人使用过这样的方法或可以推荐不同的方法？是否应该有某种文件夹结构，例如每个用户的文件夹以帮助文件访问时间？
对于任何反馈，我们都表示感谢！
我同意将图像/文件存储在文件系统而不是数据库上是一种好方法。
关于文件访问时间，如果目录包含大量文件，您可能需要检查您使用的文件系统的行为方式。如果这是一个巨大的列表，一些文件系统可能会降低性能。如果是这样，您可能想要创建一些文件夹结构，例如从 00 到 FF，这可能取决于您期望的文件数量在几个级别上。然后，您可以例如使用某个字段（如文件名）的 MD5 哈希将其排序到正确的目录中（例如，哈希 FABE063E... 进入 FA/BE/文件名）。
如果您不希望文件名被猜测以限制访问，您还可以使用一些哈希甚至随机字符串作为文件名。这样，只有知道文件名的用户（例如，通过您提供指向它的链接）才能访问该文件。如果您想移动到最终无法自己检查权限的 CDN，这可能也很重要。
（如果权限不重要并且 OTOH 想要可猜测的文件名，那么您显然会采用另一种方式，可能将用户名用作文件夹结构等。）
我认为您应该考虑引用 PresentationBase.dll，它可以让您访问由 Windows Presentation Foundation 包装的 Windows 映像组件 (WIC)。即使这是一个 ASP.NET 项目，您也可以依赖这些类进行图像编码和解码。这些类具有二进制数据或流的价值，可以对几种流行的图像格式进行解码和编码，并通过不同的解码和编码、高度和宽度在高分辨率存储中即时生成缩略图。
这些类位于 System.Windows.Media.Imaging 命名空间中，并派生自 BitmapEncoder 或 BitmapDecoder。如果您使用这些类，还可以从其他几个第三方实现中受益。
我认为就推荐的做法而言，您已经走在正确的轨道上：将有关上传文件的数据存储在数据库中，例如文件系统位置、文件名、属性、标题等，但将实际文件存储在指定的指定文件夹中明确为此目的。
此方法还允许您检查上传文件的格式限制，并在完成上传过程之前对其进行病毒扫描。
绝对不建议在数据库中存储图像等二进制内容，这种观点似乎很普遍。