如果图像存储在文件系统中，我们真的需要在数据库中存储一个表来存储图像的文件路径吗？ [英] Do we really need a table in database to store file path of image if images are stored in file system?

问题描述

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

We all store images either in database or in file system. If we store images in file system, we store a path of the image in database. We have been doing so all the time.

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

One of my colleague thought about storing images in file system, each user having a separated folder, named after their username, for storage of their images without storing a file path in database. For example, When a user sends a request to show his/her images then, we search a folder named after that user in the file system and showing all images of that folder. When a user uploads a image then it is stored in file system under his/her folder. Users cannot change their username and have no access right to change folder name.

我们真的可以省略图像路径的数据库表吗？是否可以这样设计一个系统？与此类设计相关的可能的问题是什么？

Can we really omit database table for image path? Is it ok to design a system in this way? What are the possible issues associated with this kind of design?

推荐答案

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

Can we really omit database table for image path?

当然，你可以但是（稍后） p>

Of course you can but (see later) I'd consider this solution only for very small databases.

是否可以这样设计系统？

Is it ok to design a system in this way?

$ b $

IMO it's not unless you're working with a very small amount of data, with pretty fixed requirements and easy logic around them.

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

Here long text comes. Common issues I may think about are (at least) these:

1. 如果您使用像FILESTREAM ）如删除和重命名的棘手操作将由数据库引擎正确处理。手工（有或没有文件路径存储在列中）将使你的代码更弱，除非你仔细设计这样的操作（主要是因为并发）。使用路径列写入更容易的是找到孤立的脚本。这可能（或不是）是一个问题（如您所说的用户是永远的），但这是您必须考虑的问题。


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


3. 如果您需要查询中的路径，则需要该列（例如，计算每个用户拥有的图片数量，每个用户的平均图片数量或


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


5. 如果存储图像的空间增加，那么您可以轻松添加新磁盘，如果您不必搜索正确的路径，但它存储在DB内，这很容易处理。对于不同的用户，您也可能使用不同的磁盘（速度不同），而且您不会用此类详细信息污染您的代码（图片浏览器会询问路径，因此总是不知道此类商务内容）。当然，您可以在代码中执行此操作，但随后您将在需要收集此类列表的所有位置都添加这样的逻辑，这里指向代码可维护性。


6. 存储在数据库列中的路径可以是虚拟路径（作为第5点中所述的加号），并且可以使用来自其他表的数据解析。一切都可以在SQL中完成，你的代码只会看到一个路径。如果DB没有这样的信息，那么这个计算必须在代码中完成（因为它是跨越的，所以它很难改变）。


7. 对于多个用户，重复使用图片，您只需复制其路径（假设它是只读的）即可。


8. 图片可以公开（对许多用户可见）。


9. 图片可能甚至不会存储在本地，但是在另一个服务器（通过HTTP）。如果您在DB中有路径，这是一个简单的更改，但如果您的演示文稿中包含此类代码，则很难。

1. If you use a technology like FILESTREAM (or equivalent, according to your environment) tricky operations like delete and rename will be handled correctly by database engine. Doing by hand (with or without file path stored in a column) will make your code weaker unless you carefully design such operations (primary because of concurrency). What's easier to write with a path column is the script to find orphans. This may (or not) be an issue (as you said an user is forever) but it's something you have to consider.
2. For security reasons you may setup your storage space to be read/write but not to be browsed. If you don't have a path column you need to make your storage browseable.
3. If you need paths in your queries then you need that column (for example to count how many images each user has, average number of images per user or to prepare a list without accessing disk).
4. With such column you'll be safer also from concurrency point of view. If one user is accessing the list (for example reading files) someone else may decide to delete them. If access is coordinated with a lock at table/record level then it'll work naturally but if they're unrelated then this has to be done in your code (don't underestimate this).
5. If space to store images increases then you can easily add new disks, this it's easy to handle if you don't have to search for proper path but it's stored inside DB. You may also have different disks (with different speeds) for different users and you won't pollute your code with such details (image browser will ask paths, it's always unaware of such business stuff). Of course you may do it in code but then you'll put such logic everywhere you need to gather such list, point here is code maintainability.
6. Path stored in a database column can be a virtual path (as a plus for what I said in point 5) and it may be resolved with data from other tables. Everything can be done in SQL and your code will just see a path. If DB has not such information then this calculation has to be done in code (and it'll be harder to change because it's spanned). Again point is maintainability.
7. To reuse an image for multiple users you can simply duplicate its path (assuming it's read-only).
8. Images can be made public (to be visible to many users). This information has to stay in DB but if you don't have a file path then it'll be harder.
9. Images may not even be stored locally but in another server (through HTTP). It's an easy change if you have paths in DB but it's a pain if such code is in your presentation.

请注意， 5到9暗示某种业务逻辑。它可能在数据库层（在SQL中或使用外部代码 - 例如MS SQL Server的.NET）或在DB外部的数据访问层中。这里的 true 区别在于，对于这样的列，您可以灵活地将这种逻辑放置在您喜欢的位置（根据您的特定架构，如果增加图层，也可以将其移动）。如果你没有这样的列，那么你不能在DB中放置这样的逻辑（这对于小的2层应用程序是特别糟糕的）。

Please note that points from 5 to 9 imply some kind of business logic. It may be in the database layer (in SQL or with external code - for example .NET for MS SQL Server) or in your Data Access Layer outside DB. The true difference here is that with such column you have flexibility to put such logic where you prefer (according to your specific architecture and also move it up if you increase layers). If you don't have such column then you can't simply put such logic in DB (and this is especially bad for small 2 tiers applications).

这里有一个简单的要求，它会说服我采用该路径列：

Here a simple requirement that will convince me to adopt that path column:

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).

当然，你可以在你的代码中做到这一点，但在SQL中更容易，而且更重要的一点是，跨越您的演示逻辑（插入图像，上传他们，获取列表，计算统计，建立预览...）。更重要的是：它很容易改变，不需要更新（和部署/合并）配置文件或者更糟糕的代码更改。

Of course you can do it in your code but it's easier in SQL and it's (more important) in one well-known point, not spanned across your presentation logic (to insert images, to upload them, to get the list, to calculate statistics, to build a preview...). Even more important: it's easy to change, no need to update (and to deploy/merge) configuration files or (even worse) with code changes.

我不在乎所有这些点，你不计划任何变化，以后IMO可以在数据库中删除这样的列。

If you answer "I don't care" for all these points and you're not planning any change in future then IMO you can drop such column in your database.

当然是一个设计更改，您可以重新考虑每次有新的要求（或当您发现您的演示代码知道的细节，它应该真正忽略 - 例如图像应存储在哪里）。

Of course it's a design change that you may reconsider every time you have a new requirement (or when you find your presentation code is aware of details it should really ignore - such as where an image should be stored).

这篇关于如果图像存储在文件系统中，我们真的需要在数据库中存储一个表来存储图像的文件路径吗？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！