我想知道将pdf存储在数据库表中是否是一个很好的长期想法。以下是对问题的描述：
我有一个客户，有数百个客户端上传大量pdf文件作为证据。这些pdf文件的范围从相当小（<100K）到10MB。这些文件可能会多次上传，因为它们是单个项目的证据（即proof1.pdf，proof2.pdf等）。每个客户的PDF必须保持独立，每个项目的PDF必须为每个客户保持独立。 / p>
目前，设置文件直接上传到为每个项目为每个客户创建的文件夹。这没关系，但确实占用了空间，找到文件可能有点噩梦。就像我说的那样，每个项目和每个客户都会上传多个样张。
我能想到的最佳解决方案是提供一个界面，将PDF文件直接上传到db表中，该表跟踪客户ID，项目ID和证据。这提供了更好的安全性，并且能够从项目X的每个客户获取所有PDF文件。
将开发一个数据库清理工具来删除超过指定时间段的记录，因此该表不会继续持续增长，但我担心性能损失（如果有）和其他负面因素我可能会忽视。
所以，总体来说这是一个好主意，还是我应该找到一种更好的方法来处理文件系统中的这个？
答案 0 :(得分：7)
我建议存储指向文件系统中数据的轻量级密钥，而不是将实际文件的数据存储在BLOB字段中。一种可能的安排是散列您的文件（例如，使用SHA-1）并将该散列用作磁盘上的文件名 - 甚至可能将存储安排到映射在第一个n散列字符上的目录树中（ ie ，80cdef...可能存储在storage/8/0/c/d/80cdef...）。
然后，您的表可能包含主键，文件的人性化显示名称以及包含磁盘上物理文件的（哈希）名称的字段。
这也使您可以灵活地将文件存储从数据库存储物理地分离到分布式文件系统中;这将是一个相当合理的分离，使长期系统不可避免地会变得非常大。通过这种方式，您可以保留相对较小的数据库（可能更好的性能和更少的备份痛苦）的好处，同时将更大的存储大量存储问题卸载到数据库本身之外的系统，并且已经存在过多的数据库经证实的方法。
答案 1 :(得分：0)
我倾向于回避在数据库中存储文件。我在校园里使用过Blackboard安装，你可以在该应用程序中上传文件。结果，数据库增长到无法管理的大小，超过1TB。 Blackboard的备份系统将每个课程打包为一个zip文件，并对课程进行完整备份，所有文件都必须被拉动和压缩......这成了一个漫长的过程。我们必须定期拆分（并重新拆分）备份。
以下是对此发表评论的另一篇文章： Stackoverflow post