質問
趣味のプロジェクトとしてRSSリーダーを作成していますが、ユーザーが自分のURLを追加する時点で
2つのことを考えていました。
- 各URLが1行のプレーンテキストファイル
- URLに続く一意のIDと説明を持つことができるSQLite
SQLiteのアイデアはかなりのオーバーヘッドですか、それともこのようなことをするより良い方法がありますか?
解決
OPML ファイルについてはどうですか?それはXMLなので、OPML仕様が提供するよりも多くのデータを保存する必要がある場合は、いつでも独自の名前空間を追加できます。
さらに、他のRSSリーダーからのインポートとエクスポートはすべてOPMLを介して行われます。多くの場合、ライブラリのサポートがあります。ユーザーを切り替えることに興味がある場合は、OPMLをサポートする必要があります。そのポイントを上げてくれたjameshに感謝します。
他のヒント
XMLではない理由
とにかくRSSを扱っているなら、あなたもそうかもしれません:)
URLを保存するだけですか?または、 last_fetch_time
などのデータを追加する予定ですか?
プログラムが1行ずつ読み取ってデータをダウンロードするのが単なるURLリストである場合は、ファイルに保存するか、ファイルに書き込まれたシリアル化されたオブジェクトに保存するのがよいでしょう。
それを拡張する予定がある場合、最後のフェッチのコメント/時間を追加する、など、SQLiteに行きます、それほどオーバーヘッドではありません。
インスタンスが1つしかないシングルユーザーアプリケーションの場合、SQLiteは使いすぎになる可能性があります。
表示されているとおり、いくつかのオプションがあります:
- SQLite /データベース層。コードの実行に必要な依存関係を増やします。ただし、同時アクセスを許可
- 独自のテキストパーサーを実行します。より多くのデータを保存し、車輪を再発明するにつれて、複雑さが増します。依存関係が少なく、最初は、データは単純ですが、アプリケーションの初心者ユーザーが編集するのは簡単です。
- XMLを使用します。整形式です&定義済みでテキスト編集可能。ただし、URLだけを保存するのはやり過ぎかもしれません。
- pickle などを使用してシリアル化しますオブジェクトをディスクに保存します。データ構造の変更とは、「アップグレード」を意味します。漬物ファイル。初心者ユーザー向けの編集はあまり直感的ではありませんが、実装は非常に簡単です。
XMLテキストファイルオプションを使用します。 Visual Studioに組み込まれたXSDツールを使用して、XMLデータからDataTableを作成できます。必要に応じて、簡単にシリアル化してファイルに戻すことができます。
もう1つの注意点は、エンドユーザーがRSSフィードを分類し、潜在的にそれらを検索/ソートできるようにしたいと確信していることです。そのようなデータテーブルスタイルはこれに役立ちます。
ファイルの保存とアクセスが簡単になります。これは、「データベース」の利点です。構造ですが、SQLiteのオーバーヘッドではありません。