归档平面文件的理想选择

时间:2009-02-04 15:20:47

标签: .net sql-server-2005 backup archive space-efficiency

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

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

我想知道的是每个人都认为这可能是最节省空间的方式来存储可能6个月的批量加载纯文本数据吗?

以日常SQL备份或压缩档案等形式,因此我总是能够重新加载旧数据以进行故障排除。

欢迎任何想法,我愿意接受任何建议。

6 个答案:

答案 0 :(得分:2)

使用最新一代压缩实用程序(7z和rar压缩很棒)并在组织完所有内容后压缩成捆绑包,这样很容易找到。

有7zip的SDK可与.net配合使用,以方便使用。

- 亚当

答案 1 :(得分:2)

那么,你批量加载原始数据的平面文件,你使用SQL Server 2005来处理它们并获得一组单独处理的平面文件,然后转储数据?

好吧,如果这是正确的,那么SQL备份将无济于事,因为您似乎在说数据不会留在数据库中。您唯一的选择是有效压缩输入和/或输出文件,并在目录中良好地组织批处理。

我会推荐一个积极的压缩程序,它有预定的批处理功能,但是为了避免被锁定到一个程序,请注意不要使用你使用的程序深奥......

答案 2 :(得分:2)

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

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

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

一般来说备份数据是一个棘手的问题,因为它取决于以下内容:

  • 数据吞吐量
  • 非现场备份的可用空间
  • 升级备份系统的价值,而不仅仅是在发生问题时让自己重新生成数据。

你的设置是什么样的?硬盘驱动器的增长速度是否足以保存数据的压缩版本?您是否考虑过异地备份?

答案 3 :(得分:1)

构造一个文件层次结构,适当地组织文件,压缩整个目录,并使用zip上的-u标志添加新文件。存档后,您可以删除文件,但保留目录结构为下一批添加。

如果文件名以某种方式(日期或其他)对版本进行编码,或者在其他方面是唯一的,则它不需要比signle目录更漂亮。如果没有,您需要设置目录以便恢复版本。

答案 4 :(得分:1)

压缩它们并将它们保存在数据库的二进制字段中。然后你可以构建一个“重新加载数据集”按钮来引入你的数据集(我假设你跟踪你导入的每个数据集来替换它等等)。

这样,所有内容都存储在数据库中,并与数据库一起备份,正确索引和链接,并同时进行压缩。

答案 5 :(得分:0)

您已表明您希望避免使用SDK并在远程系统上安装软件。

您的选择非常有限。

由于您使用的是Windows计算机,为什么不使用简单的脚本?

这个问题提供了一些关于如何使用Windows VBscript压缩和解压缩文件的建议:
Can Windows' built-in ZIP compression be scripted?

没有“安装”,没有SDK。只需复制脚本,通过调度程序调用它,就可以了。

- 亚当