我正在构建一个网络应用程序来处理用户和客户之间的内部电子邮件和其他常见的中小型文本块。存储这些数据的最佳方法是什么？在数据库（MySQL）中还是作为数千个单独的文件？压缩它（PHP 的 gzcompress() 或 MySQL 的压缩特性）怎么样？
这将不是一个公共应用程序，因此用户负载将是最小的（一次少于 20 个用户）。然而，应用程序中每天都会有大量的通信来回进行，所以我预计随着时间的推移数据量会增长得相当大（这就是我想压缩它的原因）。
我想将数据保存在数据库中以便于访问和移植，但是我在这里看到的一些关于图像的线程建议使用文件存储。你怎么看？
谢谢你，赛斯
编辑澄清：我不需要对文本进行任何形式的搜索，这就是为什么我倾向于压缩它以节省空间。
对于已经采用特定格式的图像和文档（excel、word 文档、pdf 文件等），我更喜欢文件存储。但对于原始文本，我可能更愿意使用数据库。跨机器复制以进行故障转移更容易，您可以对文本进行子字符串搜索，虽然我不知道用于压缩它的特定算法，但我认为数据库会是更好的方法。但前提是您已经只有文本并且它只是文本。我更喜欢使用文件存储的任何其他格式的文档。
除非我遗漏了什么，否则我会使用 CLOB 而不是 BLOB，如果它只是文本的话。
将文件保存在数据库中的主要原因之一是使其与您存储的其余数据保持一致。使用预定义的数据集进行备份、（重新）部署等将更容易。此外，更容易保证事务的完整性。
将文本存储为文件的好处之一可能是使用网络服务器更容易为它们提供服务，如果这是使用文件的唯一剩余好处，您可以考虑在网络服务器上缓存文件——这将为您提供很多数据库的简单备份和事务，但同时允许一些 http 请求的加速。
我会选择使用数据库。您描述了要存储大量消息的场景。您没有提供有关系统的太多信息，但我猜您可能希望对消息进行排序、分组和应用其他几个属性。将消息及其属性保存在数据库中而不是使用文件存储会更容易并且可能更快。
在压缩方面，我不知道哪种方法最有效。您可能应该在选择之前尝试两者。
我想知道这个“中等块”有多大。如果文本只是写入消息（因此小于 10 KB），那么压缩会使它们变得更小，并且不会对数据库增长产生太大影响。它使开发和维护也变得更加容易，让所有东西都可以通过单一查询获得，而不必单独获取文件内容。