ストレージフォーマットをどのように決定するか、またそれらのいくつかの使用例は何ですか？
プログラムデータを保存する方法はいくつかあります（ゲーム、従業員データベース、プログラム構成などにファイルを保存します）。
- プレーンテキスト（
.iniおよび.conf） - XML
- データベース（MySQL、SQLite ...）
.Zipおよびいくつかのファイルを含む類似のもの（異なるフォーマット）- バイナリファイル（
.docなど。たとえば、シリアル化ツールによって作成されます）
上記のフォーマットのさまざまな使用例は何ですか？それらの利点と欠点の対比（速度、柔軟性、ファイルサイズ、使いやすさなどを考えてください）？異なるタスクのためにそれらをどのように決めるのですか？
zip形式について：これは、他のファイルを含めるためにのみ使用されます。別の圧縮形式の場合もあります。これにより、画像ファイル、音声ファイル、テキストファイルなど、いくつかのファイルの構造が可能になります。例として、ファイルを含むメッセージの保存形式があるとします。 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++）で最も簡単です。高度に調整されたバイナリ形式は、速度とサイズの両方で他のすべてよりも優れています。
特効薬はありません。私の経験では：
プレーンテキスト記憶媒体は自動的にnoになるため。スキーマと型の安全性を備えた.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 [〜＃〜]：同時にまたは頻繁に変更されない小さなサイズの構造化データ。
- データベース：大きな構造化データまたは同時アクセスが必要です。アプリケーションでは、クエリと検索の必要性が必須です。
- バイナリデータ：ストリーミングオブジェクトにのみ使用します。
- zipは、サーバー上のデータベースを除く上記のいずれかの別のプロセスとして追加できる圧縮です。
XMLは、テキスト（処理が難しい/処理が遅い）とバイナリ（読み取り不能）の最悪の機能を組み合わせていると聞きました。