0

JVMに変換中のレガシーLAMPアプリケーションがあります。

問題の問題は、@250Kレコードのスコアリングテーブルを伴います。現在、「scoreType」列はtinyintとして表されています。ここで、1 =ゴール、2 =アシスト1、3=アシスト2です。

スコアリングリーダーの場合、各プレーヤーのゴール/アシスト1 /アシスト2の合計を取得するには、クエリスニペットは次のようになります。

SUM(IF(scoreType=1,1,0)) AS goals, SUM(IF(scoreType=2,1,IF(scoreType=3,1,0))) AS assists

十分に公平ですが、クエリコンテキストがSUM、COUNTなどの操作を伴う一般的なスキーマ設計の観点から、 goal / assert1 / assert2、winなどの限られた選択肢セットを分割する方がよいかどうか疑問に思います。 / loss / tieなどをtinyintアプローチではなく、別々の列に分割しますか？

別の列では、クエリは次のようになります。

SUM(goal) AS goal, SUM(assist1) AS assist1, SUM(assist2) AS assist2

これは、わずかに増加したストレージ（3列対1）を犠牲にして、パフォーマンスの向上（if（cond、a、b）一致の必要はありません）です。

アプリケーション層では、1つの潜在的な大きなメリットは、ORMでサポートされていないSUM（if（））からcolumn.Sum（）に移行することです。それ以外の場合は、オールインワン列アプローチで非静的に型指定された文字列SQLクエリを保持する必要があります

考え？どのように対処するか、そのままにするか、DBとアプリケーションコードを3列のアプローチに移行しますか？

フィードバックをありがとう！

4

1 に答える 1

1 
SELECT scoreType, COUNT(scoreType)
FROM ...
GROUP BY scoreType

じゃないですか。

選択肢を比較するための正直なタイミングについては、より冗長なものを使用してください。

SELECT COUNT(CASE WHEN scoreType = 1 THEN id ELSE NULL END) AS goals,
       ...
于 2012-04-26T12:11:10.697 に答える