eie*_*fai 40 database-tuning architecture
可能的重复：
文件 - 在数据库中与否？
我想知道是否有任何充分的理由仍然在数据库中使用 blob 字段。几年前，我使用了一个包含一堆图像的数据库，该数据库非常慢，我看不出有什么好的理由将图像保存在数据库中，所以我将图像取出并存储了文件名反而。
这是明智之举吗？你代替我做什么？
Eri*_*elp 30
正如您从其他答案中可以看出的，这是一个很大的“视情况而定”。其他一些因素可能是，如果您为托管付费，他们是否会为文件存储或数据库存储收取更多费用。文件存储通常更便宜，尤其是对于云服务。
如果您是自托管并使用 SQL Server，即将推出的代号 Denali 的版本将扩展 FILESTREAM以允许通过 TSQL 和文件系统进行访问。它还将确保这些保持同步。您可以从任何一侧访问、更新、删除，这将使一切井井有条。
做你的研究，找出对你来说重要的东西，然后根据那个选择来选择方向。
Gai*_*ius 17
使用 BLOB 的原因很简单，可管理性 - 您只有一种方法来备份和恢复数据库，您可以轻松进行增量备份，图像及其存储在数据库表中的元数据不同步的风险为零，您还有一个编程接口来运行查询或加载/保存图像，因此您无需授予远程客户端文件系统访问权限，并且您知道相同的 GRANT 将应用于图像及其相关数据。此外，您还有一种存储管理方法（例如，在 Oracle 中，您可以将所有内容都放在 ASM 上并使用 Oracle 作为您的 LVM 来处理所有内容）。
另一个应用是将关系数据与序列化对象混合（BLOB 可以是任何二进制文件，它不需要是图像）。或者，您可以对 BLOB 中的关系数据和字节 xy 运行查询，例如，这可能是一个文件头。应用程序实际上是无穷无尽的。
如果访问 BLOB 比访问文件系统慢，那么很可能是您的数据库配置错误。
Joe*_*Joe 13
我不使用 blob——主要是从备份和恢复的角度来看，因为我不希望 blob 数据减慢我的备份速度。
我不存储完整的 URL，但是......我只将文件路径存储在某个点以下，并构建路径，因为人们和程序访问我的文件的方式不止一种（FTP、HTTP、本地目录、 NFS 挂载目录）。
...当然，我可能会处理比大多数人更多和更大的图像......我的一个数据集每天获得大约 700GB 的图像（压缩）。但即使是那些图像的缩略图，我仍然存储在外部。
小智 8
我非常喜欢将图像的“参考”副本存储在数据库中——从可管理性/灾难恢复的角度来看，这确实是一种可行的方法。
现在，您仍然可以做很多事情来为大多数应用程序提供文件系统之外的图像，因此您不会对数据库服务器本身施加太大的压力来做它并不真正想做的事情。
小智 5
我不太喜欢在数据库中存储图像。在一个只有几个用户的小应用程序中，这似乎是一个简单的解决方案，但是当您开始扩展时，它会使事情变得更加困难。
我的偏好是开始将图像存储在 Web 服务器上的文件夹中，但将路径保持在易于访问的配置中，以便在需要时可以快速将它们移动到他们自己的专用、优化的图像服务器。稍后，我可能想以同样的方式将它们移到其他地方（想想 S3 或 Akamai）。如果我必须更改一直期望从数据库中读取它们的代码，那么所有这些都会变得更加复杂。
这是明智之举吗？
这是否是明智之举，取决于您的具体情况：
如果文件位置直接影响任何 url 结构，或者如果您在数据库中存储完整的文件地址（不好），我可以说这是一个不好的举动，因为万一有人移动或重命名某些目录，您会遇到麻烦。
但如果您的应用程序是以一种只需指向文件目录并且文件访问逻辑是动态的方式构建的，那么您出于以下原因做出了明智的举动：
通过数据库存储，如果需要为每个请求提供大量图像，您将增加应用程序的响应时间，因为文件将同步发送到网络。此外，您还将向服务器添加更多处理。
文件存储通常比数据库存储便宜。
通过文件存储（除非对图像访问有限制：只有确定的用户才能访问给定的一组图像），无需任何处理即可访问图像或任何其他类型的文件。
使用数据库存储，无法使用 FTP 访问文件（很明显，但最好记住）。
数据库文件存储会减慢和/或使数据库定期备份变得混乱。
如果你处在我的位置，你会做什么？
除非出现相反的主导因素，否则我将保留该决定。
希望有帮助。
| 归档时间： |
|
| 查看次数： |
41713 次 |
| 最近记录： |