我想知道将 pdf 存储在数据库表中是否是一个长期的好主意。以下是问题的描述:
我有一个客户，有数百个客户上传大量 pdf 文件作为证明。这些 pdf 文件的大小从相当小 (< 100K) 到 10MB 不等。这些文件可能会被多次上传，因为它们是单个项目的证明(即 proof1.pdf、proof2.pdf 等)。每个客户的 PDF 必须保持独立，每个项目的 PDF 必须对每个客户保持独立。
目前，它的设置是将文件直接上传到为每个项目的每个客户创建的文件夹中。这没问题，但确实会占用空间，而且查找文件可能有点像一场噩梦。正如我所说，将为每个项目和每个客户上传多个证明。
我能想到的最佳解决方案是提供一个接口(interface)，将 PDF 文件直接上传到数据库表中，该表跟踪客户 ID、项目 ID 和证明。这提供了更好的安全性，并提供了从每个客户那里获取项目 X 的所有 PDF 文件的能力。
将开发一个数据库清理工具来删除超过指定时间段的记录，因此表不会永远持续增长，但我担心性能下降(如果有的话)和其他负面影响我可能忽略了这一点。
那么，总的来说这是个好主意还是我应该想出一个更好的方法来在文件系统中处理这个问题？
最佳答案
我建议在文件系统中存储指向数据的轻量级 key ，而不是将实际文件的数据存储在 BLOB 字段中。一种可能的安排是对您的文件进行哈希处理(例如，使用 SHA-1)并将该哈希用作磁盘上的文件名 - 甚至可能将存储安排到映射到第一个 n 的目录树中散列字符(即，80cdef... 可能存储在storage/8/0/c/d/80cdef...)。
然后，您的表可能包含一个主键、一个文件的人性化显示名称，以及一个包含磁盘上物理文件的(散列)名称的字段。
这也使您可以灵活地将文件存储从数据库存储中物理分离到分布式文件系统中；在一个规模将不可避免地变得非常大的长期系统中，这将是一个相当合理的分离。通过这种方式，您可以保留相对较小的数据库的优势(可能更好的性能和更少的备份痛苦)，同时将更困难的海量存储问题卸载到数据库本身之外存在的系统，并且已经有过多的存储空间。行之有效的方法。
关于mysql - 是否使用 Blob (mysql + coldfusion)，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/5811244/