5

ここでユーザー設定の保存に関するいくつかの質問を見てきましたが、それらは主にかなり最小限の設定について言及しているようです。私は現在、非常に多くの設定を保存する必要がある高度にカスタマイズ可能な Web アプリに取り組んでおり、それらを保存する方法に苦労しています。

保存するプリファレンスの種類には、特定のツールチップを表示するためのブール値、ページ上のさまざまなコンテンツ パネルの配置、ログイン後に表示するページ、特定のフォーム フィールドのデフォルト値などが含まれます。ユーザーごとにこのタイプの 50 以上の設定があり、データはほとんどがブール値と整数であると予想されます。

私はシリアル化の大ファンではありませんが、各設定を個別の行として格納するスケーラビリティについて懸念しています。考え?

4

7 に答える 7

6

データのブロブをシリアル化することはここに行く方法ですが、パフォーマンス上の理由からではありません。これは、システムの側面であり、膨大な数の変更が発生する可能性があるためです。あるページなどで詳細モードをオンにする設定を許可する必要があるという理由だけで、DBスキーマを変更する必要はありません。

HLGEMが言及しているエンティティ属性値モデルは、「進化しやすい」という観点からはこれに適合しますが、彼女が言うように、パフォーマンスは非常に低くなります。

シリアル化されたオブジェクトをあきらめるのは、特定のパターンに一致するユーザーをデータベースに直接クエリする機能です(おそらく、設定のいくつかの組み合わせでのみ発生するバグを追跡していて、何かがあるかどうかを確認したい場合があります)その組み合わせを持っているユーザー)。

于 2009-09-22T06:08:42.787 に答える
5

非常にパフォーマンスの悪いシステムが必要でない限り、エンティティ属性値構造 ( http://en.wikipedia.org/wiki/Entity-Attribute-Value_model ) を使用しないでください。50 列の 1 つのテーブルへの呼び出しは、必要なすべての情報を取得するために 50 回結合する必要がある 1 つのテーブルへの呼び出しよりもはるかに高速になります。

設定のクエリ方法に基づいて、設定の一般的なグループ (ログイン設定、サイト全体の設定、特定のページまたは機能の設定) ごとに関連するテーブルを作成します (ログイン時にすべてをプルしたい場合は、それらをプルします)。ログイン時にサイト全体に必要なものと、ユーザーがそれらにアクセスしたときに特定の領域にのみ必要なもの (これらのいくつかの組み合わせ) と、その中に設定された設定のタイプのブール列があります。こうすることで、サイトの各領域に必要なすべての設定が同じテーブル、または多くても 2 つまたは 3 つのテーブルに格納され、情報を比較的簡単に取得できるようになります。これは、デザインがパフォーマンスにとって重要な場所の 1 つです (設定を常に調べているため、ミリ秒もカウントされます)。そのため、デザインではパフォーマンスを最初に考慮する必要があります。

于 2009-07-29T14:41:39.757 に答える
1

設定を検索する必要がない場合は、いつでも設定を XML として保存し、「設定」列に保存できます。将来的に新しい設定を追加するのが少し簡単になるはずです;)

于 2009-07-29T20:08:07.053 に答える
0

あなたができる別のオプション(たとえば、アイテムの統計をチェックするためにDBにアイテムを保存する必要がない場合(誰が何をするかなど))、すべての設定をCookieに入れて、機械。

もちろん、Cookie には、Cookie の使用に関するすべての注意事項があります。しかし、別のアイデア...

于 2009-07-29T20:14:35.603 に答える
0

ユーザーデータがすでにデータベースに保存されていると仮定すると、特にデータに基づいてクエリを実行する必要がある場合は、すべてを1行に保存することに実際の問題は見られません。プリファレンス A または B などを持つすべてのユーザーを選択します。

ただし、それをクラスにロードし、ある種のキャッシュメカニズムを介してそのクラスを永続化します。

于 2009-07-29T20:04:10.370 に答える
0

ユーザーがより好む特定の設定があります (すべての動物は平等ですが、一部の動物は他の動物よりも平等です)。これらは、ログイン時のインターフェイスでの取得と適用のために特に最適化する必要があります。好みの深さが下がるにつれて、それらは任意の基準を使用して集約され、おそらく配列として個別の列として保存されます (たとえば、フォントの好みの列にはフォントの種類、サイズ、色が含まれ、フォント テーブルが参照されます)。また、db ツールを使用して使用頻度の高い列にインデックスを付け、再設計して集計された列を分割し、集計内のどの要素が需要が高いかを特定できるようにします。

全体として、ユーザー設定は非常に静的である傾向があります (つまり、習慣のようなものです)。より高度に変更可能なユーザー データを設定と混同しないでください。

于 2009-09-22T06:57:38.207 に答える
0

ユーザー設定などの情報をデータベースに保存するかどうかさえわかりません。ユーザーがログインするとすぐに、多くの (すべてではないにしても) ユーザー設定を確認する必要があるようです。大量の db クエリを実行すると、システムが非常に遅くなります。代わりに、ユーザーのすべての設定を単一のファイル (またはどこかの単一のレコード) に保持し、ユーザーがログインするとすぐにそれを飲み込んでキャッシュすることをお勧めします。

于 2009-07-29T19:59:10.837 に答える