归档平面文件的理想选项

Question

目前，我们每周都会收到数千份平面文件，我有一个系统可以运行这些文件的报告，并将其导出为PDF供我们的人员处理和参考。

我目前将它们批量加载到数据库中，确保所有字段/格式都有效，导出它们，并在下一次运行时截断这些表。

我想知道的是，每个人都认为存储这种批量加载的纯文本数据可能需要6个月的最节省空间的方法是什么？

无论是以每日SQL备份的形式，还是以压缩归档的形式，或者其他任何形式，所以我总是能够重新加载旧数据以排除故障。

任何想法都是受欢迎的，我愿意接受任何建议。

Answer 1

因此，您批量加载原始数据的平面文件，使用SQL Server 2005对其进行处理，并获得一组单独的处理后的平面文件，然后转储数据？

好吧，如果这是正确的，SQL备份将不会有任何帮助，因为您似乎是在说数据不会留在数据库中。您唯一的选择是对输入和/或输出文件进行有效压缩，并在目录中对批处理进行良好的组织。

我会推荐一个积极的压缩程序，它有预定的批处理功能，但要小心不要与你使用的程序变得晦涩难懂，以免被锁定在一个程序中……

Answer 2

使用最新一代的压缩实用程序(7z和rar压缩效果很好)，并在组织所有内容后将其压缩成包，这样就很容易找到。

有适用于7zip的SDK可以与.net一起使用来简化这一点。

-Adam

Answer 3

分析后的数据有两种类型：

• 原始数据(通常非常大)
• 派生数据(通常较小)

在您的情况下，派生数据可能是进入报表的数据。对于您的原始数据，我只需为其创建一个巨大的压缩存档文件，并根据数据的日期和类型使用系统名称。这样做的价值在于，如果团队中的某个新手以某种方式完全删除了将原始数据导入数据库的代码，您可以从中恢复。如果派生数据很小，您可以考虑将其复制到另一个数据库表中，或者将其保存在单独的平面文件中，因为只需获取派生数据就可以解决一些问题。

备份数据通常是一个棘手的问题，因为它取决于以下内容：

升级备份系统的异地backups

• Value所需的
• data throughput
• Available空间量，而不是在发生问题时自行重新生成数据。

你的设置是什么样的？硬盘的增长速度是否足以容纳数据的压缩版本？您是否考虑过异地备份？