ストレージフォーマットをどのように決定するか、またそれらのいくつかの使用例は何ですか？

プログラムデータを保存する方法はいくつかあります（ゲーム、従業員データベース、プログラム構成などにファイルを保存します）。

• プレーンテキスト（考える.iniと.conf）
• XML
• データベース（MySQL、SQLite ...）
• .zip および類似のいくつかのファイルを含む（異なる形式で）
• バイナリファイル（.docたとえば、シリアル化ツールによって作成されたものなど）

上記のフォーマットのさまざまな使用例は何ですか？それらの長所と短所の対比（速度、柔軟性、ファイルサイズ、使いやすさなどを考えてください）？異なるタスクのためにそれらをどのように決めるのですか？

zip形式について：これは、他のファイルを格納するためだけに使用されます。別の圧縮形式の場合もあります。これにより、イメージファイル、サウンドファイル、テキストファイルなど、いくつかのファイルの構造が可能になります。例として、ファイルを含むメッセージの保存形式があるとします。次のファイルを圧縮ファイル内に含めることができます。

message.txt (containing the message)
attachments (folder containing attachments)
  audio.wav
  picture.jpg

私は次のように使用します：

プレーンテキスト

構成用-通常はYAMLまたは.iniを使用します。テキストファイルが望ましい結果である場合を除いて、ほとんどの用途で非推奨（例：テキストへの印刷、テキストへの保存など）

XML

データの構成と転送用。例：エクスポート、XSLTによるフォーマットなど。移植可能なファイル形式（例：SVG）として適しています。優れた操作ツールとフィルター。

データベース

app / webapp内からのメインデータストレージ。選択したストレージとして、常にそれを使用してください。信頼性が高く、堅牢で、多くの機能が組み込まれています（トランザクション、参照整合性、カスケード削除/更新、インデックス、速度）。レイヤーまたはORM（IMO）での使用に最適です。

単一ファイルのアーカイブ（.zipなど）

エミュレータのROMイメージなど、関連する複数のバイナリストリームをコンパクトに格納するのに適しています。頻繁に更新する必要がない、または更新する必要がないものに最適です。重量があり、遅く、操作が難しい。

バイナリ

アプリデータの保存にデータベースが利用できない場合のみ。シリアライゼーション（C ++）で最も簡単です。高度に調整されたバイナリ形式は、速度とサイズの両方で他のすべてよりも優れています。

特効薬はありません。私の経験では：

記憶媒体としてのプレーンテキストは自動的にありません。スキーマと型の安全性を備えた.configファイルでカバーする方がよいと考えるいくつかのケースです。型の安全性とデータ抽出の必要性はほとんど常に生じます。プレーンテキストはこのプロセスを悪夢にします。

XML：タイプセーフティ、データ検証、少量、場合によっては使用します。.NETには、オブジェクトのXMLシリアル化に対する強力な組み込みサポートがあるためです。

データベース：私のデフォルト。タイプセーフティ、速度、トランザクション、十分に信頼され、何かが計画通りに進まなかった場合に、DBをストレージメディアとして選択することに責任を負うのは困難です。

.zipは圧縮形式ですが、これがどのように永続化に適合するかはわかりません。

バイナリ：一時的なメモリストリームを作成する必要がある場合にのみ、バイナリを使用します。Binaryは、データがスキーマで編成されているDBまたはXMLと比較して、クエリ機能の点で価値を追加しません。

使いやすさは相対的であり、具体的に何を達成したいかによって異なります。速度については、ボリュームに関して上記で述べた以外の点では同じです。ファイルサイズが問題で適切な正規化が適用されている場合は、zipまたはその他の圧縮形式で圧縮しますが、これは別のプロセスです。

次のように使用します。

平文

そのカテゴリにYAMLやプロパティファイルなど、もう少し複雑な形式が含まれている場合は、ユーザーが手作業で読んだり編集したりすることを期待する場合に最適なオプションです。もう1つの大きな利点は、小さなスクリプト（たとえばsed）を使用して変更できることです。

シンプルさと使いやすさに勝るものはありません。サポートチームがリモートマシン上で何かを構成する必要がある場合（クライアントの問題を解決するなど）、またはITがソフトウェアを実行するサーバーの束を再構成する必要がある場合、この形式を選択していただきありがとうございます。それはまた、彼らのためにそれを行ういくつかの単発的なソフトウェアを書くことからあなたを救うでしょう。

XML

ここで@Ingoに同意します。プレーンテキストとは異なり、XMLはスクリプトで処理するのが難しく、手作業で編集するのは悪夢です。

それでも、YAMLが解読できなくなるような複雑な構造のデータがあり、それでも人間が読み取りおよび編集できるようにしたい場合は、XMLがおそらく最良の選択です。

関係データベース

大量のデータ（プレーンテキストやXMLが扱いにくくなる）があり、サードパーティがSQLコマンドやGUIを使用して手動で編集できるようにする場合に最適です。

もう1つの利点は、コンテンツを管理するコードが非常に読みやすいことです。@ Richard-Harrisonは、彼の優れた答えの中で他の利点の良いリストを提供しました。

NoSQLデータベース

RDBMSに対する1つの利点は、配布によるスケーラビリティです。これは、おそらく質問にはあまり関係ありません。おそらくより関連性のある利点は、キー値ストアの単純さとスキーマレスの柔軟性です（これは一言ですか？）。リレーショナルパラダイムに違反していることに気付いたときは、ブロブをデータベースに保存し、キーでアクセスし、コードを介して処理するだけで、このオプションを検討してください。一部の選択肢（CouchDBなど）は移植性が高く、フットプリントが小さく、スケーリングも可能なため、MySQLやSQLiteの優れた非リレーショナル代替手段を提供します。

バイナリ

バイナリの利点は、高速でコンパクトなことです。ファイルを読み取って変更する必要があるのはプログラムだけであり、データがリレーショナルパラダイムに適合しない場合や速度が本当に重要な場合は、これが適切な選択になる場合があります。おそらくメディアファイルに最適です。

最初の設計時に考慮されなかった理由のために、プログラムデータへの単純なアクセスがいつの時点でも必要とされない場合にまだ遭遇していないことを指摘しておきます。今日私は個人的に、標準フォーマットを持ち、他のソフトウェア（オーディオ、ビデオなど）でエンコード/デコードする必要のあるファイル以外のデータベースオプションを選択しています。

注：バイナリは不透明であり、何とか安全性が高いという一般的な誤解があります。追加の保護なしではそれは不可能です-誰かがあなたのソフトウェアをハッキングしたいなら、あなたの設定をバイナリで保存するだけでそれらを止めることはできません。

圧縮アーカイブ

上記の代替策ではなく、追加の対策です。

ネットワーク経由でデータを送信する必要がある場合、または大量のデータを保存してスペースを節約したい場合に有利です。最近のストレージ容量は通常豊富であるため、ターゲットプラットフォームを検討してください。

今日ほとんどすべて（ムーアの法則、ベイビー）で非常に高速に実行するため、これを使用しない唯一の理由は、コードが複雑になることです。それほど複雑ではありませんが、それでもKISSの原則に違反しています。手動で、またはスクリプトを介して編集する必要のある構成ファイルの場合は特に扱いにくく、スペースを本当に節約する必要がある場合は、おそらくデータベースオプションを使用する必要があります。

私はそれらを次のように使用します：

• プレーンテキスト：アプリケーションのサイズが単純な構造化データ（例の名前と値のペア）が小さい。複数のユーザーが同時にデータを変更することはありません。
• XML：同時にまたは頻繁に変更されない小さなサイズの構造化データ。
• データベース：大きな構造化データまたは同時アクセスが必要です。アプリケーションでは、クエリと検索の必要性が必須です。
• バイナリデータ：ストリーミングオブジェクトにのみ使用します。
• ジッピングは、サーバ上のデータベース以外は、上記のいずれかのための別のプロセスとして添加することができる圧縮です。

XMLはテキスト（処理が難しい/処理が遅い）とバイナリ（読み取り不能）の最悪の機能を組み合わせていると聞きました。