我应该将文件存储在数据库中还是只存储该文件的位置？答案

【问题标题】：Should I store file in database or just the location to that file?我应该将文件存储在数据库中还是只存储该文件的位置？
【发布时间】：2010-11-25 02:45:52
【问题描述】：

存储文件的更好做法是什么？直接将文件存储在数据库中还是只存储该文件的位置？

【问题讨论】：

我很惊讶 - 这个问题仍在公开讨论/辩论中？而且它不是任何重复的，嗯...
看起来与dba.stackexchange.com/questions/2445/…类似

标签： database file file-upload

【解决方案1】：

避免在数据库中存储文件。大多数人都不能很好地处理它们。

【讨论】：

补充一下，这通常是一个坏主意——它唯一变得甚至远程可行的时候是当你处理一个数据库时，你可以保证记录在你需要时会在内存中，因此从那里送达。但在几乎所有情况下，文件系统都更适合它。
我发现很难在数据库中存储大于 10mb 的文件，而文件系统多年来一直很好。
还是不知道 MySQL 中的 BLOB 和 CLOB 是干什么用的？
@truong-ha，BLOB 和 CLOBS 对于较小的相关信息很有用，比如文件的校验和。有更好的工具来提供文件。

【解决方案2】：

这取决于。您需要考虑几件事情。

如果您有一个米老鼠免费软件数据库，这意味着它不能正确处理 blob（读取每个 SELECT 上的 blob；不会将 blob 存储在行的单独物理结构中； blob 非常慢；等等)
- 将文件保留在外面，只存储位置
- 手动处理 row.location 与文件系统的同步
如果您有企业 SQL 平台，将 blob 保留在数据库中完全没有问题。事实上，检索更快。这些不会读取每个 SELECT 上的 blob，它们存储在与行不同的物理结构中。如果SELECT 请求获取 blob，则额外读取一次，这不是“性能问题”。
正版SQL数据库中的PAGESIZE可以设置为2k； 4k； 8k；或 16k。
- 2k 非常适合 OLTP（小行、小事务：您不想在每个 IO 操作上移动 8K）
- 更大的尺寸取决于您满足多少 OLAP
  - 在您的情况下，文件的平均大小
  - 最后一页的未使用部分会有一些浪费，每行/blob。
将 blob 保留在数据库中的缺点是，您的数据库备份会大大增加。
- 某些企业数据库（例如 SAP/Sybase）识别出页面未更改，并将其从增量备份中排除
- 其他人没有增量数据库备份。
将 blob 保存在数据库中的优点是：
- 数据和参照完整性。您不会遇到与 blob 不同步的行的问题
- blob 包含在备份中：否则，在恢复时，将恢复的数据库与恢复的文件同步的任务是一个主要问题。
- 我去年完成了一项任务，客户在数据库中有 130GB 的数据，在数据库之外存储了 700GB 的文档。经过十年的问题，他们咬紧牙关，将文档移入数据库。
  猜猜看，本应是一项简单的工作（冗长但简单，因为引用应该是绝对正确的），最终变得庞大，因为有很多 (a) 重复和 (b) 无效引用。生成的数据库为 630GB，其中有 100GB 的欺骗。 2K 页面大小。

评论回复

斜线或反斜线
很简单。
- 在数据库中，仅存储斜线。
- 您需要一种识别目标系统的方法和一个IsWindoze 指示符。它应该在表层次结构中较高，而不是在 Filename 所在的级别。
- 每当您报告或显示Filename 列时，如果是IsWindoze，请将斜杠更改为反斜杠。
DriveLetter 和冒号D: 会有类似的问题，而 Unix 则没有。仅当 IsWindoze 时才允许。

【讨论】：

谢谢老哥，看了好几篇还是采纳吧。
我必须将文件存储在可能位于不同类型操作系统上的系统上，而我遇到的一件愚蠢的事情是斜杠 (/) 或反斜杠 (/) 的物理路径文件。
@Truong：谢谢。我在答案中添加了回复。
SQLite 是米老鼠数据库吗？
@9716278 1) 所有免费软件“sql”和Oracle都是米老鼠：不兼容SQL，有额外的功能，但不是核心要求。 PostGres 是最糟糕的，它甚至没有真正的语言，或者 ACID Transactions。 2) SQLite 是 mickey mouse lite。

【解决方案3】：

迟到的答案：这取决于您的引擎。

自 1990 年代以来，SQL Server 没有使用 2k 的页面大小。 Oracle 默认为 8K，SQL Server 为 8K。只有 Sybase AFAIK 还停留在上个世纪。
SQL Server 现在提供 FILESTREAM，它结合了两全其美，正如 Oracle 长期以来使用 BFILE 所做的那样
SQL Server 和 Oracle 提供磁盘和备份压缩

我确信 PostgresSQL 至少提供了类似的功能。

注意：这主要是为了提供 PerformanceDBA 的 FUD 的替代方案

【讨论】：

1) 如果行很小（关系规范化），那么在每个 I/O 操作上传输 8K 是愚蠢的，但那是 MS SQL Server。特别是如果它是一个高吞吐量的 OLTP 系统。此外，PageLocks 的锁定粒度会更大，并发性会受到影响。哦等等，你有RecordIds；广泛的记录；和行级锁定，没有OLTP的概念。 2) SAP/Sybase 拥有华尔街 95% 的市场（提示：高端 OLTP）。 Wall St 仍然使用 2GB 磁盘。 3) PostGres 是反 SQL 的。 4) 替代品 ? Q 与压缩无关。

【解决方案4】：

首选方法是将文件存储在文件系统中，并将文件的位置存储在数据库中。其原因与数据库如何在磁盘上物理分配空间（通常为 8k 或 16k 块）有关。将大文件放在那里会导致您的数据库使用不同的机制来存储文件（SQL Server 称之为row overflow data）。通常，这类页面位于普通表之外，因此对一行的每次逻辑读取都会导致磁盘上的两次物理读取。不用说，这对性能不利。

【讨论】：