Database 若图像存储在文件系统中，我们真的需要数据库中的一个表来存储图像的文件路径吗？

我们都将图像存储在数据库或文件系统中。若我们在文件系统中存储图像，那个么我们在数据库中存储图像的路径。我们一直在这样做

我的一位同事考虑将图像存储在文件系统中，每个用户都有一个单独的文件夹，以他们的用户名命名，用于存储他们的图像，而无需在数据库中存储文件路径。例如，当用户发送显示其图像的请求时，我们在文件系统中搜索以该用户命名的文件夹，并显示该文件夹的所有图像。当用户上传图像时，它会存储在他/她的文件夹下的文件系统中。用户无法更改其用户名，并且没有更改文件夹名称的访问权限

我们真的可以省略图像路径的数据库表吗？这样设计一个系统可以吗？与这种设计相关的可能问题有哪些

我们真的可以省略图像路径的数据库表吗

当然，你可以，但是（稍后）我会考虑这个解决方案，只针对非常小的数据库。

这样设计一个系统可以吗

在我看来，除非您处理的数据量非常小，并且有非常固定的需求和简单的逻辑

与这种设计相关的可能问题有哪些

这里是长文本。我可能会想到的常见问题（至少）有：

如果您使用诸如FILESTREAM之类的技术（或根据您的环境而定的等效技术），数据库引擎将正确处理诸如删除和重命名之类的棘手操作。手工操作（有或没有文件路径存储在列中）会使代码变得更弱，除非您仔细设计此类操作（主要是因为并发性）。使用path列更容易编写的是查找孤立项的脚本。这可能（或不）是一个问题（正如你所说的用户是永远的），但这是你必须考虑的问题。

出于安全原因您可以将存储空间设置为读/写，但不可浏览。如果没有路径列，则需要使存储可浏览

如果查询中需要路径，则需要该列（例如，计算每个用户有多少图像、每个用户的平均图像数或在不访问磁盘的情况下准备列表）

从并发性的角度来看，有了这样的专栏，您也会更加安全。如果一个用户正在访问列表（例如读取文件），其他人可能会决定删除它们。如果访问与表/记录级别的锁相协调，那么它将正常工作，但是如果它们不相关，那么这必须在代码中完成（不要低估这一点）

如果存储图像的空间增加，则可以轻松添加新磁盘，如果不必搜索正确的路径，但存储在DB中，则很容易处理。您也可以为不同的用户使用不同的磁盘（速度不同），这样您就不会用这些细节污染代码（图像浏览器会询问路径，它总是不知道这些业务内容）。当然，您可以在代码中这样做，但随后您将把这样的逻辑放在您需要收集这样的列表的任何地方，这里的重点是代码可维护性

存储在数据库列中的路径可以是虚拟路径（作为我在第5点中所说的补充），并且可以使用其他表中的数据来解析。一切都可以在SQL中完成，您的代码只会看到一条路径。若DB并没有这样的信息，那个么这个计算必须在代码中完成（因为它的跨度很大，所以很难更改）。第二点是可维护性

要为多个用户重复使用图像，您只需复制其路径（假设它是只读的）

图像可以公开（对许多用户可见）。这些信息必须保存在数据库中，但如果没有文件路径，则会更加困难

图像甚至可以存储在另一台服务器中（通过HTTP），而不是本地存储。如果在DB中有路径，这是一个简单的更改，但是如果在演示文稿中有这样的代码，这是一个痛苦的过程

请注意，从5点到9点暗示了某种业务逻辑。它可能位于数据库层（在SQL中或使用外部代码-例如.NET for MS SQL Server）或数据库外部的数据访问层中。这里真正的区别在于，有了这样的专栏，您可以灵活地将这样的逻辑放在您喜欢的地方（根据您的特定架构，如果您增加了层，还可以将其向上移动）。如果您没有这样的列，那么就不能简单地将这样的逻辑放在DB中（这对于小型2层应用程序来说尤其糟糕）

下面是一个简单的要求，它将说服我采用该路径列：

Store images bigger than 10 MB on path \\BIGDISK\IMAGES. Images smaller than 10 MB are on D:\IMAGES. Premium users always stores on D:\IMAGES. Trial users will store on remote server http://example.com/very_slow_storage). 在路径\\BIGDISK\images上存储大于10 MB的图像。 小于10 MB的图像位于D:\Images上。 高级用户始终存储在D:\IMAGES上。 试用用户将存储在远程服务器上http://example.com/very_slow_storage). 当然，您可以在代码中实现这一点，但在SQL中更容易实现，而且（更重要的是）在一个众所周知的点上实现，而不是跨越整个表示逻辑（插入图像、上载图像、获取列表、计算统计数据、构建预览…）。更重要的是：它很容易更改，不需要更新（和部署/合并）配置文件，或者（更糟糕的是）更改代码

如果您对所有这些问题回答“我不在乎”，并且您不打算在将来进行任何更改，那么在我看来，您可以在数据库中删除此类列

---

当然，这是一种设计变更，您可以在每次有新需求时重新考虑（或者当您发现您的演示代码知道应该忽略的细节时，例如图像应该存储在何处）。

数据库中的列用于元数据和并发性。F