Mysql 将附件保存到数据库：blob与路径引用

我正在设计一个系统，在这个系统中可以创建一个条目，然后向该条目添加附件，然后将附件保存到数据库中。然而，对于如何实施附件处理，我有两个想法

我正在两种方法之间进行斗争：

将附件直接保存为blob字段类型

将目录路径保存到数据库文件中，并将实际文件保存到服务器

现在，就我所知，这两种方法各有利弊

第一种方法是将所有数据保持在同一个位置，以便我可以轻松地将其移动到其他位置。此外，就“数据在哪里”这一问题而言，它还保持了一致性。另一方面，我听说保存这样的东西非常耗费资源，数据库的大小将大幅度增长

第二种方法允许数据库保留易于管理的数据字段，如文本和数字，而服务器上的数据越重。这还允许在必要时更直接地访问文件。另一方面，数据是分离的，更难跟踪，还需要引入文件系统访问以检索所述文件

我倾向于第一种方法，但为此，我希望能回答以下问题：

将附件直接保存到数据库会如何影响数据库的大小和大小 应用程序性能

---

不要将文档作为blob存储在数据库中。存储路径。RDBMS不是文档存储。MySQL不是为这个目的而设计的，在MySQL中存储文档会使数据库的大小变得不必要的巨大，几乎不可能进行数据检索，备份会花费很长的时间，如果数据库发生问题，所有文件都会随之发生。文件存储几乎总是比RDBMS更好的文件存储选择。

我有一个类似的问题，我认为我采取的方法取决于所需的附件类型 在我的例子中，我所做的是打开主要是文本的附件，并简单地将数据放在DB中（而不是DB简单地存储附件）

---

这使我能够以一种简单的方式查看内容内部（当然这与您期望的更新数量有关）

“永远不要”是一种严重的夸大padiwan@Sam为什么？请告诉我一些理由，因为我看到的应用程序确实将文件直接保存到数据库，所以很明显有人认为这是个好主意。@Grietom请看我的answer@Grietom仅仅因为有人做了，并不意味着这是一个好主意，也不意味着这是一个坏主意！OTOH，tt可能会使数据库变得非常庞大！如果你的文件存储发生了什么事情，它会带走你的文件。也许有可信的论据支持你，但我不认为这些是真的。@草莓哈哈，是的，有两个视频以blob的形式存储do@Strawberry像s3这样有数百个备份发行版的文件存储几乎永远不会失败，而EBS上的硬盘故障是很常见的。此外，举例来说，对于I/O来说，EBS的价格要比S3高很多。如果你认为我的理由不充分，就用你的观点来回答。我很想了解更多。我想知道你们是否都不知道是否有人研究过，当存储一定数量和大小的文件时，数据库会变得多大、多慢？我不能给你们指出一项研究，但我正在进行一个1 TB数据的项目，MySQL运行良好。如果数据库设计正确，性能不会随大小而变化（假设它有资源和RAM可利用）。并发性是一个完全不同的主题。在我的例子中，附件几乎可以是任何东西：pdf、屏幕截图、office文档、纯文本等。基本上是一个文件，它总是增加了新的复杂性。