我们的应用程序根据客户端配置的规则结构处理数据。 在处理过程中，每一步都会生成一个详细的“日志”，以便用户了解原因和结果。最终处理结果背后的逻辑......以及限制（或规则或其他）发挥作用。
您如何将这些数据存储在数据库中？
我敢打赌，从一个日志记录到下一个日志记录，95％以上的数据是多余的。我在100条记录的合并文本上运行了LZMA，输出大小为2％。
仅检索文本以供主键显示。从不查询过滤或搜索目的。 每条记录的平均文本大约为25k。
如果我压缩每条记录的文本，我将达到~10％压缩...而2％压缩（对于合并的100条记录）。
理想情况下，我想使用从大量现有数据中生成的某种固定字典。
我们正在使用SQL 2005.我知道SQL 2008有行和版本。页面级压缩选项..但目前无法让我们的整个客户群升级。
思考？ 谢谢！
更新：这就是我所做的。
经过一周的实验阅读后，我编写了一个程序，在1000条记录的组合文本上生成LZW样式字符串字典。然后，我以各种方式对字典进行优先排序，包括：
- 预计总体节省（以字节为单位，通过替换）
- 预期节省，仅包括每个记录出现1次或更少次数的字典条目。
我在示例记录上运行了最高优先级X（100和1000之间）字典条目的简单替换。然后使用LZMA alg。压缩编码输出。
通过使用字典的不同配置...我发现充其量，我可以将LZMA压缩提高约1％。在大多数情况下，我引入的熵比我提取的更多，因此编码的LZMA压缩数据大于比原始数据压缩w / LZMA。
我已经确定LZMA可以利用每个记录的文本中的冗余比行之间有更多的冗余。
所以我很可能只会LZMA所有的文字，并称之为一天。
答案 0 :(得分：1)
我能想到在SQL 2005中完成此类压缩的唯一方法是使用您自己的SQL CLR对象创建自定义框架。这将是一个非常复杂的解决方案，但它可能适合您的目的。升级到SQL 2008可能更容易，更经济。
SQL CLR功能和/或触发器可用于管理压缩＆amp;有问题的表上的解压缩操作......性能可能不是最优的，我不知道。您还需要某种字典管理实用程序。可能会创建某种定期维护，负责定期更新和优化固定字典（如果需要）。
虽然这不是您问题的直接解决方案，但我认为您可能会发现以下有关Code Project的文章很有意思 -
Using CLR integration to compress BLOBs/CLOBs in SQL Server 2005
正如您所看到的，本文作者以非常聪明的方式使用SQL CLR来解决SQL 2005上的不同压缩问题。
答案 1 :(得分：0)
如果它大部分是相同的文本，可能会采取更多的关系方法，您可以在数据库中存储消息输出的范围，并有一个包含messageID的表和使消息唯一的不同参数？