我们都知道有关使用数据库进行文件存储（具体是图像）的讨论已经失去了多少论点和生命。在决定如何继续我的项目时，我有点蠢。
我有一个允许管理员上传员工照片的网站。目前，这些图片存储在我的MySQL数据库中的BLOB中。此外，我有一个与网站一起运行的Windows应用程序。该应用程序使员工能够在他们成功完成后打卡并显示他们的图片。通过应用程序内的mysql查询（从非本地远程位置）检索图片，该查询将图像内容转换为在图片框中输出的可读图像，从而确认雇员的身份。
在我看来，将图像存储在数据库中并通过简单查询检索它们要容易得多。我发现这比在数据库中存储图像路径和处理下载图像的应用程序要容易得多。我也不必处理冲突，文件夹组织和安全性以及因x，y等原因而重写的路径等。
存储在数据库中的图像在裁剪成一定大小后仅为20 kb。我的问题是，是否仍然需要使用图像路径嵌入数据库，还是应该像现在一样存储它们？如果在这种情况下将图像存储在数据库中仍然是不明智的，是否有正式的方法来存储图像路径？
对此的任何帮助将不胜感激。如果这个问题不属于这里，我会乐意移动它。
答案 0 :(得分：13)
如果图像是用户数据，而不是应用程序代码或主题的一部分，那么将图像存储在数据库中是一个好主意，因为......
如果您需要备份的只是数据库，则备份更容易管理。另一方面，如果您将一些应用程序数据存储在数据库中，而某些应用程序数据存储在文件系统中，那么您必须协调数据库和文件系统的备份计划，以确保两者的一致性。
如果你有一个数据库管理员，那就太好了！您的备份应该已经完成。如果没有，那么设置数据库备份可能有点棘手，但是一旦你有备份系统，它可能比文件系统备份更好。例如，许多数据库系统都支持流复制。
当然，在文件系统上拥有图像也有其优点，即性能和简单性，因为大多数Web服务器都是为了提供静态文件而构建的。混合方法可以为您提供两全其美的优势：
答案 1 :(得分：9)
我认为将图像存储在数据库中是一个坏主意有几个原因：
1）服务器将具有与数据库无法跟踪的文件相关联的时间戳信息。如果出于法医原因需要这样做，数据库解决方案在这方面可能会受到限制。您也可以随时在DB中保存有关IP信息，时间戳等上传图像的信息。
2）如果您希望这些文件被其他系统/服务使用，您将不得不经常引用数据库并与之交互，这时您可以更轻松地定位特定文件夹。
3）每当需要检索图像时，您必须打开与数据库的连接才能生成它。这可能会为通过指向文件夹更容易实现的事物添加额外的代码和步骤。
为了避免命名冲突，如果我在Linux机器上，我会使用类似Unix时间戳的东西作为文件名保存时的前缀，或者只是使用它（+可能是短随机＃）作为图像ID完全一样。所以不是'jane-image.jpg'，而是'1407369600_img3547.jpg'。然后，只需在DB和中提琴中引用它，这是一个随机的ID，在那里永远不会发生碰撞，除非时间开始向后流动。无论什么样的Windows时间戳等价物都会被使用，显然。
注意：你现在正在做的事情并不坏，从听起来它可能最适合你...但一般来说我尽量不把所有东西都放在数据库的手中，只因为我能。但那就是我:)