0

さまざまな方法で「ポイント」を獲得できるユーザーと一緒にアプリを作成しています。これらのポイントの発生の一部は、プロファイル、実行したアクションなど (つまり、複数のテーブルに分散) が原因で発生します。

数値の一貫性を確保したいので、特定のアクションが発生したときにフィールドに手動でポイントを追加したくありません。簡単にクエリできるように、フィールドでポイントを更新し続ける何らかの計算フィールドが必要です。これは、一連のユーザーとそのポイント (トップ 100 リストなど) をリストするたびに、非常に複雑な選択/ビューを実行したくないためです。

複数の他のテーブルに対して複雑な select ステートメントを使用して users テーブルのフィールドを計算する方法はありますか? 効率的ですか？計算されたフィールドを捨てて、よく書かれた手順を使用する必要がありますか?

4

3 に答える 3

2

複数のテーブルにまたがる場合は、これらのテーブルを使用するビュー、またはユーザー定義のテーブル/スカラー (要件に応じて) 関数を使用してこれらの値を取得することをお勧めします。

于 2009-12-05T11:47:16.980 に答える
0

あなたのアプローチは合理的に聞こえますが、多くの場合、SQL 設計が本番環境に移行してヒットし始めると、SQL 設計を非正規化する必要があります。

これを行うには多くの方法があります。T-SQL を使用してこれを行う 1 つの方法を次に示します。

SELECT
    u.Id,
    u.UserName,
    t.Point_Total
FROM User u
INNER JOIN (
     SELECT Id, SUM (Points) AS Point_Total
     FROM (
        SELECT Id, Points FROM TableA
        UNION ALL   --Be **SURE** to include "ALL"
        SELECT Id, Points FROM TableB
        UNION ALL
        SELECT Id, 5 AS Points FROM SpecialCondition
     GROUP BY Id
     ) t ON t.Id = u.Id

スキーマとデータの分布に応じて、他にも多くの方法があるため、実験してパフォーマンスを追跡する必要があります。

于 2009-12-05T11:47:10.180 に答える
0

ポイントの詳細を 1 つのテーブルにまとめてみませんか? テーブル内の行は、UserId、Item、Points のようなものになる可能性があります。そのため、特定のユーザーがアイテムごとに異なるポイントを持つ複数の行を持つことができ、レポート目的で合計を簡単に合計できます。

数値の一貫性を確保することに関する懸念については、トランザクションで調整を行うだけで済みます。これは、データ アクセスを管理する一連のストアド プロシージャを使用して簡単に管理できます。たとえば、プロファイル内の特定のデータの存在に対して 5 ポイントを言及しました。そのデータがプロファイルに追加されると、同じトランザクションで、新しい行をポイント テーブルに挿入します。

そうしないと、複数の結合でこの種のものを管理しようとして、数値を頻繁に報告する必要がある場合、非常に遅くなる可能性が非常に高くなります。

于 2009-12-05T12:06:44.807 に答える