私は現在IRCクライアントを作成しています。私は、サーバー設定を保存する良い方法を見つけようとしています。基本的には、ほとんどのIRCクライアントが持つネットワークとそのサーバの大きなリストです。設定の保存：XML対SQLite？
私はSQLiteを使用することを決めましたが、他のIRCアプリケーションで使用するために、リストをXMLフォーマットでオンラインで自由に利用できるようにしたいと思いました。だから今は設定をローカルに同じフォーマットで保存するだけかもしれません。
私はADO.NETまたはXMLのいずれかの経験がほとんどないため、このような状況でどのように比較するのかはわかりません。
プログラムで作業する方が簡単ですか？ 1つは速いですか？それは問題ですか？
あなたが気づいているよりも漠然とした質問です。 「設定」には、非常に多くのことが含まれます。
設定ファイルのアプリケーション設定を処理するための優れた.NETインフラストラクチャがあります。これらは一般的に、グローバルSettingsオブジェクトのプロパティとしてプログラムに公開されます。 System.Configuration名前空間のクラスは読み込みと永続化を行い、Visual Studioに組み込まれているツールを使用してそれらを処理するコードを自動生成します。このインフラストラクチャでサポートされているデータ型の1つはStringCollectionなので、これを使用してサーバーの一覧を格納できます。
しかし、サーバーの大規模なリストについては、これが私の最初の選択ではない、いくつかの理由があります。私はあなたのリスト内の要素は単純な文字列ではなく、実際にはタプル（ホスト名、ポート、説明など）であることを期待しています。その場合、データをフォーマットして解析してStringCollectionにする必要があります。それは一般的にあなたが何か他のことをしているはずのサインです。また、アプリケーションの設定は読み取り専用で（少なくともVistaでは）、設定可能なユーザースコープを永続化できるようにすることができますが、コミットする前に理解したいと思うパスを導きます。
それでは、別のことを考えてみましょう。サーバーのリストは単にリストですか、それともそれを表す内部オブジェクトモデルがありますか？後者の場合、XML直列化を使用してオブジェクトを格納および取得することを検討します。 （アプリケーション設定ファイルに残す唯一のことは、シリアライズされたオブジェクトファイルへのパスです）シンプルなオブジェクトをXMLにシリアライズおよびデシリアライズするのは本当に簡単なので、私はこれを行います。適切なシリアライズフォーマットを設計してテストすることに関心を持っているわけではありません。
データベースを使用する主な理由は、自分のプログラムが原子と耐久性を必要とする操作の束を実行している場合、または何らかの理由ですべてのデータを一度にメモリに入れたくない場合です。 Xが起こるたびに、私はそれを永久的に記録しておきたい、それはデータベースを使う方向に私を導いてくれます。そのようなものにはXMLシリアル化を使用する必要はありません。すべてのオブジェクトを1つの物理ファイルに保存する場合は、1つのオブジェクトだけを実際にはシリアル化できないからです。 （実際には、私の会社の製品とまったく同じですが、私はデータベースを使用しないという別の状況を指摘しています。データのスキーマが
"原子と耐久性"が何を意味するのかよく分かりませんが、説明できますか？ –
これらは両方ともトランザクションの属性です。アトムのように、トランザクションは分割できません。トランザクション内のすべての操作が実行されるか、まったく実行されません。 「耐久性」とは、いったんトランザクションがコミットされると、それが何らかの形で保存され、例えば外に出る電力に耐えられることを意味します。 （それらも一貫性があり、分離されています：ACIDのWikipediaエントリーを参照してください） –
私は個人的に設定にXMLを使用します - .NETはこれを行うために既に構築されているため、XML設定ファイルに設定を保存するための多くの組み込み機能があります。
設定を保存するためのカスタムスキーマ（XMLまたはDB）を使用する場合は、データストアのまわりにまともなAPIを使用する必要があるため、XMLまたはSQLiteのいずれかがうまく機能すると言います。
SQLiteの.NETラッパーがあります – Sorantis
すべてのツールは、独自の権利
XML arroundの誇大広告の多くがあります持っている、私は知っています。しかし、XMLは基本的に交換フォーマットであり、記憶フォーマットではありません（ネイティブXMLを使用しない限り、より多くのオプションを提供しますが、頭痛を加えるかもしれません）。
設定がかなり小さい（たとえば10.000レコード未満）場合は、XMLを使用しても問題ありません。すべてのものをあなたのメモリにロードし、そのエントリにアクセスします。完了しました。
しかし、設定が非常に大きい場合、完全にロードする必要はありません。デシジョンを考え直し、必要な設定の部分を動的にロードするオプションを提供するSQLiteを使用してください。
DBコンテンツからXMLファイルを作成するための小さなツールを提供することもできます.DBからXMLを作成するのは簡単な作業です。
Webサーバーとデスクトップクライアント（これは伝統的にはこれらが実行されるため）はそれぞれ独自の記憶域が必要です。
サーバー側では、Xmlではなくリレーショナルデータストアを使用します。基本的には、ユーザーデータとサーバー上の他のユーザーデータを分離しておく必要があります。 XMLはそのための良い店ではありません。
クライアントでは、実際には問題ありません。おそらくXmlはあなたが操作する方が簡単でしょう。あなたが1つの設定で1つのテクノロジーを使用しているので、別の設定でそれを使用する必要があるとは思わないでください。
私はXMLファイルを他の人が使用できるようにWeb上で提供することを指していました。 –
永続性はウェブとファイルの問題です。データをデータベースに格納してから、必要に応じて結果をxmlに変換するほうが簡単です。データベースは永続化を容易にします（大丈夫、簡単です）。 –
ああ、私はそれを考えなかった、ありがとう。 –
このリストはどのくらいですか？レコードはいくつですか？ – tuinstoel
おそらく数百人に。 –