数据库中的 Blob 或指向文件的指针？ [复制]答案

【问题标题】：Blob in DB or pointer to file? [duplicate]数据库中的 Blob 或指向文件的指针？ [复制]
【发布时间】：2014-02-16 23:49:45
【问题描述】：

可能重复：
When to store images in a database(mySQL) and when not? (Linking image to item in database)
Which is the best method to store files on the server (in database or storing the location alone)?

我应该考虑在使用数据库存储 MP3/pdf 之间做出最佳选择。将文件作为 BLOB 存储在数据库中会更好吗？还是只有一个允许我查看文件系统的字段更好？

有问题的文件不太可能超过 15MiB，但都可能至少 1MiB，以防万一。

数据将通过 PHP 访问，如果有影响的话...

编辑：我将继续我已经在做的事情:) 文件系统上的资源以及数据库中的文件名。谢谢或输入！

【问题讨论】：

考虑在文件系统中复制/移动/备份文件有多好。考虑使用数据库中的文件进行痛苦的数据库备份。等
这已经被问了一百万次了。这两种解决方案都有充分的理由。对于小型/中型文件，数据库实际上可能更快。至少有一个 DBMS 是：research.microsoft.com/apps/pubs/default.aspx?id=64525（如果找不到其他 DBMS（如 Postgres、Oracle 或 MySQL）的类似阈值，我不会感到惊讶）
或在这里：stackoverflow.com/questions/8407372/…
公平地说，我确实在寻找重复项。我想我的 stackoverflow-fu 不如我的 google-fu 好！我希望我能给出两个答案，但由于马修福斯卡里尼有更深入和广泛的考虑，我觉得我必须选择他的答案。非常感谢 Mike Brant 提供更多信息供您参考！

标签： php mysql

【解决方案1】：

过去 3 年我一直在从事一个项目，其中大型附件存储在数据库中。

优势

与处理关联文件相比，管理数据库中的记录更容易，代码也更少。
即使使用 CakePHP 的行为来自动执行任务。数据库更简单。
一些项目有将数据保存在数据库中的安全要求（即使它并没有真正提高安全性）。
自动构建过程可以轻松备份数据，因为它已经在数据库中了。

缺点

为开发创建数据库快照是一件很痛苦的事情。
在您传递了几个 GB 的大小之后。不管人家怎么告诉你。您会开始怀疑数据库引擎是否可以处理它。
转储数据库开始需要很长时间。
向不同架构的数据迁移开始需要非 SQL 解决方案。

关于 DB Blob 的神话

您的数据库无法处理大型数据库文件。
硬盘上的一个坏扇区意味着您可能会丢失所有 blob 数据。
存储在数据库中会产生性能成本。
这样更安全。
从数据库读取并发送到客户端比读取文件并发送要慢。

以上所有（根据我的经验）都是错误。

关于大斑点的事实

总有一天，您不再希望它在数据库中。
GUID 记录标识符是您的朋友。不要在文件名中使用记录 (int)ID。
您不需要反向从文件名中查找记录，但您需要从记录中查找文件。因此，您可以只使用 guid 作为文件名。
备份/复制文件系统和小型数据库比仅备份大型数据库更容易。
不要将文件存储在您的 webroot 中。

【讨论】：

我可以在这个 Q 关闭之前获得 +1 吗？大声笑
哈哈！我认为这个答案绝对值得 +1
很好的总结。我不确定我是否购买了备份的问题。 DBMS 也可以进行非常有效的差异/增量备份。当您需要获取数据库的完整转储时，您可能还需要文件的“转储”，而复制的时间与数据库转储一样长（可能更长，因为有很多文件）
我同意。转储 1GB 比复制总共 1MB 的 100,000 个文件要快，但我的生产数据库是远程的。因此，仅仅为了验证错误而下载 20GB 的转储文件是一件很痛苦的事情。
谢谢马修·福斯卡里尼。这回答了我的问题。

【解决方案2】：

我认为对于大多数用例来说，仅存储文件路径是最好的方法。对我来说，这种方法的优点包括：

对于用户可以下载的图像或其他文件的情况，您可以让客户端直接下载/缓存文件。
如果将来某个时候需要，允许实施 CDN（即，只需更新数据库中的文件引用
它将大大减少在应用程序和数据库之间传回的数据量，潜在地消除额外的带宽使用（如果数据库位于远程服务器上）并使您的查询响应更快（从而不会占用您的数据库）。
它使数据库备份速度更快。
它允许您对资产使用传统的文件管理技术。

有一些存储 blob 的潜在用例：

也许您想对资产执行某种二进制搜索（尽管很容易认为有比 MySQL 更好的解决方案）。
出于某种原因，您需要保证没有孤立文件或没有实际文件的条目（即提交图像事务）

【讨论】：

您也应该列出缺点：没有事务存储。需要做家务，两种不同的备份和恢复计划，需要将文件均匀分布在目录中（因为没有文件系统可以处理单个目录中的数百万个文件）
@a_horse_with_no_name 这些是有效点。实际情况是，一旦您达到拥有数百万个文件的地步，您确实应该使用完全不同的存储解决方案（而不是服务器本地存储），更像是 Amazon S3。

【解决方案3】：

最好的办法是将文件保存在上传目录中，然后将该位置传递给 MySQL

【讨论】：

请允许我解释一下，希望删除那个讨厌的 -1 :p，在一个合并的位置进行管理比处理存储 blob 的损坏或其他此类问题要容易得多
哇，你的评论改变了一切。仍然 -1 ;)
Stackoverflow，如此苛刻的情妇。也许 op 可以阅读与同一主题相关的 10k 其他问题并为自己选择。
在文件系统中有文件确实不会整合任何东西。你实际上是在四处传播东西。当您拥有数据库中的所有内容时，您就真正实现了整合，因为您只需要一个备份和恢复策略来维护和测试。