現在、週に数千のフラット ファイルを受け取ります。私は、これらのレポートを実行し、従業員が処理して参照できるように PDF にエクスポートするシステムを持っています。
現在、これらをデータベースに一括ロードし、すべてのフィールド/フォーマットが有効であることを確認し、エクスポートして、次回の実行時にテーブルを切り捨てます。
私が疑問に思っているのは、このバルク ロードのプレーン テキスト データをおそらく 6 か月分保存する最もスペース効率の良い方法は、誰もが考えていることでしょうか?
毎日の SQL バックアップ、zip アーカイブなどの形式で、トラブルシューティングのために古いデータを常にリロードすることができました。
どんなアイデアでも大歓迎です。どんな提案も歓迎します。
最新世代の圧縮ユーティリティ（7zおよびrar圧縮は優れています）を使用し、すべてを整理した後でバンドルに圧縮して、簡単に見つけられるようにします。
これを簡単にするために.netと連携する7zip用のSDKがあります。
-アダム
つまり、生データのフラットファイルを一括ロードし、SQL Server 2005を使用してそれらを処理し、処理されたフラットファイルの個別の束を取得してから、データをダンプしますか？
これが正しければ、データがDBに残っていないと言っているように見えるので、SQLバックアップは役に立ちません。唯一のオプションは、入力ファイルや出力ファイルを効率的に圧縮し、ディレクトリ内のバッチを適切に編成することです。
バッチ機能がスケジュールされている積極的な圧縮プログラムをお勧めしますが、1つのプログラムに固定されないようにするために、使用するプログラムで難解にならないように注意してください...
分析後のデータには、次の 2 種類があります。
あなたの場合、派生データはレポートに入るデータである可能性があります。元のデータについては、日付とデータの種類に基づいた体系的な名前を付けた巨大な圧縮アーカイブ ファイルを作成するだけです。これの価値は、チームの初心者が元のデータをデータベースにインポートするコードを何らかの形で完全に消去した場合、そこから回復できることです。派生データが小さい場合は、それを別のデータベース テーブルにコピーするか、別のフラット ファイルに保存することを検討してください。これは、派生データを取得するだけで問題の一部が解決される可能性があるためです。
一般的に、データのバックアップは難しい問題です。これは、次のような要因に依存するためです。
セットアップはどうですか？ハードドライブは、データの圧縮バージョンを保持するのに十分な速さで拡張できますか? オフサイトのバックアップについて考えたことはありますか?
それらを圧縮し、データベースのバイナリフィールドに保存します。次に、「データセットの再読み込み」ボタンを作成して、データセットを取り込むことができます（インポートして置き換える各データセットを追跡していることを前提としています）。
このようにして、すべてがデータベースに保存され、データベースでバックアップされ、正しくインデックス付けおよびリンクされ、同時に圧縮されます。
ファイルを適切に整理するファイル階層を構築し、ディレクトリ全体をzipして、zipの-uフラグを使用して新しいファイルを追加します。ファイルをアーカイブした後、ファイルを削除できますが、次のバッチを追加するためにディレクトリ構造を保持します。
ファイル名がバージョンを何らかの形でエンコードしている場合（日付など）、またはその他の点で一意である場合は、signleディレクトリよりも凝ったものである必要はありません。そうでない場合は、バージョンを回復できるようにディレクトリを設定する必要があります。