問題タブ [storage]

Greasemonkey を使用してサイトをクロールしたいのですが、値を一時的に保存するには、GM_setValue を使用するよりも良い方法があるのではないかと考えています。

私がやりたいことは、ソーシャル ネットワークで連絡先をクロールし、プロフィール ページから Twitter の URL を抽出することです。

私の現在の計画は、各プロファイルを独自のタブで開くことです。これにより、通常の閲覧者のように見えます (つまり、css、スクリプト、画像はブラウザーによって読み込まれます)。次に、GM_setValue を使用して Twitter の URL を保存します。すべてのプロファイル ページがクロールされたら、保存された値を使用してページを作成します。

ただし、ストレージオプションにはあまり満足していません。多分もっと良い方法がありますか？

ユーザー プロファイルを現在のページに挿入して、同じスクリプト インスタンスでそれらをすべて処理できるようにすることを検討しましたが、XMLHttpRequest が通常のユーザーが開始した要求と区別できないように見えるかどうかはわかりません。

内部メールや、ユーザーとクライアントの間で頻繁にやり取りされる小規模から中規模のテキストのチャンクを処理する Web アプリを構築しています。このデータを保存するための最良の方法は何ですか? データベース (MySQL) または何千もの個別のファイルとして? それを圧縮するのはどうですか (PHP の gzcompress() または MySQL の圧縮機能)?

これは公開アプリケーションではないため、ユーザーの負荷は最小限に抑えられます (一度に 20 ユーザー未満)。ただ、アプリ内では毎日大量の通信が行われるので、時間の経過とともにデータ量がかなり増えることが予想されます（そのため、圧縮したいのです）。

アクセスと移植性を容易にするためにデータをデータベースに保持したいのですが、ここで見た画像に関するスレッドのいくつかは、ファイル ストレージの使用を提案しています。どう思いますか？

ありがとう、セス

明確にするために編集：テキストを検索する必要はありません。そのため、スペースを節約するためにテキストを圧縮することに傾いています。

バックグラウンド：

ずっと前に実装された社内のドキュメントストレージシステムがあります。何らかの理由で、ドキュメントの保存メカニズムとしてデータベースを使用することが選択されました。

私の質問はこれです：

ドキュメントを保存するためのベストプラクティスは何ですか？選択肢は何ですか？長所と短所は何ですか？ 回答はテクノロジーやプラットフォーム固有である必要はありません。より一般的なベストプラクティスの質問です。

私の考え：

データベースはドキュメントの保存を目的としたものではありません。ファイルシステムまたはサードパーティのドキュメント管理システムの方が便利な場合があります。データベースのドキュメントストレージは高価です。操作が遅い。これらの論理的な仮定はありますか？おそらくこれが最善ですが、私の考えでは、より良い選択肢があります。oracle BFILE（NASまたはSAN上のドキュメントへのリンク）はBLOB / CLOBよりも優れているでしょうか？

詳細：

• ドキュメントにはさまざまな種類があります（pdf、word、xml）
• 中間層コードは.net2.0/ c＃で記述されています
• ドキュメントは、圧縮されたBLOBのOracle 10gデータベースに保存されます（NASストレージ）
• ファイルサイズが激怒
• ドキュメントの数は大幅に増加しており、減速の兆候はありません
• インサートは通常、ピーク時に1時間あたり数百になります
• 取得は通常、ピーク時に1時間あたり数千になります
• NASストレージとSANストレージが利用可能です

更新（以下の質問から）：

• 私のバックグラウンドは開発です
• データベース内のファイルの横に保存されているファイルに関するメタデータが関連付けられています

ユーザーが画像をアップロードして「使用」できるサイトを構築しています。私が欲しいのは、一時的なアップロードを管理する方法についての考えとアイデアです。

たとえば、あるユーザーが画像をアップロードしたものの、それに対して何もしないことに決め、サイトを離れてしまったとします。次に、ファイルをサーバーにアップロードするか、サーバーのメモリにロードしましたが、画像をいつ削除できるかを知るにはどうすればよいですか? 最初は、定期的に空にする一時的なアップロード フォルダーを用意することだけを考えましたが、もっと良いものがあるに違いないのではないでしょうか?

ところで、私は CakePHP と MySQL を使用しています。画像はサーバーに保存されますが、場所のみが dbb に保存されます。

mosso CloudFiles を Google AppEngine で実行されているアプリケーションと統合しようとした人がいるかどうか疑問に思っています (mosso はテスト サンドボックスを提供していないため、登録しないと自分で確認できません)。コードを見ると、AppEngine 環境の httplib と urllib の制限により、これは機能しないようですが、誰かが cloudfiles にパッチを当てたのでしょうか?

プラットフォームは理論ほど重要ではありません。記録としては、ASP.NET（3.5 SP1のC＃）、SQL Server 2005です。議論のために、私は無制限のスペース（ファイルシステムとデータベース）と無制限の帯域幅を持っています。

私は、複数のユーザーが自分の画像をアップロードできるようにするプロジェクトに取り組んでいます。この画像は、そのユーザーが管理し、すべてのユーザーが表示できます。私は最良のストレージメカニズムが何であるかを判断しようとしています。私の考えでは、画像に関する情報の保存は確認できましたが、データベースに直接保存することは避けたいと考えています。

私が見ているのは、ユーザーが画像をアップロードするということです。サーバーは、画像の一意の名前を作成し、それをファイルシステムに保存し、その画像に関するリレーショナルデータをデータベースに保存します（つまり、画像がアップロードされたとき、ユーザーへの関連付け、キャプションへの参照など）。これらをディスク上に置くことは、将来CDNに移行できるようにするための1つのステップです。

誰かがこのようなアプローチを使用したことがありますか、または別のアプローチを推奨できますか？ファイルアクセス時間を支援するために、各ユーザー用のフォルダーなど、ある種のフォルダー構造が必要ですか？

フィードバックをいただければ幸いです。

セッション ストレージが複数のページに対してセッション グローバルであるという理由以外に、ビューステートを使用して値を保持する必要があるのはなぜでしょうか?

値のようないくつかの小さなクエリ文字列以外のあらゆる種類の情報を、クライアントとサーバーの間でやり取りするのは、ばかげているように思えます。つまり、単にストレージの目的で帯域幅を浪費する (!) ことです。セッションは、複数のページにわたってグローバルですが、viewstate の完全に優れた代替手段のようです。

特に、asp.net の ajax コントロールとバリアントでは、viewstate がすぐに肥大化し、さまざまなコントロールと html 要素すべてのさまざまな状態と変数を追跡する可能性があります。

しかし、ページ変数とオブジェクトのビューステート ストレージが存在するのはなぜでしょうか?

ページのビューステート ストレージの別の優れた使用法を見逃している可能性があります。何か知っている人はいますか?

読んでくれてありがとう！

編集：誰もが素晴らしい答えを持っていました。あなたの答えを選ばなかったらごめんなさい。

重複の可能性:
Lucene.Net および SQL Server

PDF やオフィス ファイルなどのファイルを保存し、インデックスを作成する必要があります。現在、Sql Server 2k8 を使用して、IFilters による全文検索を使用してこのタスクを実行しています。私の質問は次のとおりです。これは「最良の」方法ですか？たとえば、インデックス作成のために Lucene に切り替える必要がありますか?

ユーザー プロファイルのプレゼンテーション イメージのアップロード関数を .NET で作成しています。私はそれを行うための 2 つの異なる方法から選択しています。長所と短所についてアドバイスや意見を求めたいと思います。

1. イメージをファイル システムに直接保存する

2. 画像をデータベースに保存する

これまでのところ、私は主に最初のオプションを支持してきました。各ユーザーは 1 つのプレゼンテーション画像しか持てないため、ユーザー名にちなんで画像に名前を付けます。次に、ユーザーが画像を持っている場合は指定されたパスでチェックを行い、そうでない場合はデフォルトの「画像なし」の画像を表示します。

これについて私が気に入っているもう 1 つの点は、DB のスペースを節約できることです。追加のバイナリ ロードがなければ、DB はかなり重くなります。

他にも考えていない部分があると思いますので、ご意見をお聞かせいただければ幸いです。誰かが問題に対して根本的に異なる解決策を持っている場合は、それも共有してください!