0

私は保険業界向けの Web API に取り組んでおり、保険の見積もりに適したデータ構造を考え出そうとしています。

データベースには、基本的に次の「評価」テーブルが既に含まれています。

sysID (PK, INT IDENTITY)
goods_type (VARCHAR(16))
suminsured_min (DECIMAL(9,2))
suminsured_max (DECIMAL(9,2))
percent_premium (DECIMAL(9,6))
[Unique Index on goods_type, suminsured_min and suminsured_max]

[編集] 商品の種類ごとに、通常、保険金額の範囲が 3 ～ 4 あります [/編集]

goods_types のリストはめったに変更されず、ほとんどの保険のクエリには 100 ドル未満の商品が含まれます。このため、次の形式のテーブルを使用して非正規化することを検討していました ($0.00 から $100.00 までのすべての値)。

Table Name: tblRates[goodstype]
suminsured (DECIMAL(9,2)) Primary Key
premium (DECIMAL(9,2))

このデータの非正規化は維持が容易なはずです。レートは通常、多くても 1 か月に 1 回しか更新されないからです。$100 を超える値に対するすべてのリクエストは、常にプライマリ テーブルで検索され、計算されます。

私の質問は次のとおり
です。 1. 加算された値を DECIMAL(9,2) または BIGINT に格納されたセントの値として格納する方が良いですか?
2. この非正規化方法では、10,001 個の値 ($0.00 から $0.01 の増分で $100.00) をおそらく 20 個のテーブルに格納します。これは、percent_premium を調べて計算を実行するよりも効率的でしょうか? - または、メイン テーブルに固執して計算を行う必要がありますか?

4

3 に答える 3

4

新しいテーブルを作成しないでください。商品、最小値、最大値のインデックスが既にあるため、(既知の商品とその値) に対する次の sql は次のようになります。

SELECT percent_premium 
FROM ratings 
WHERE goods='PRECIOUST' and :PREC_VALUE BETWEEN suminsured_min AND suminsured_max

インデックスを効率的に使用します。

探しているデータ型はsmallmoneyです。これを使って。

于 2009-02-02T11:11:35.827 に答える
1

あなたが提案する計画では、 orの代わりにbinary searchon行を使用します。1000134

それはほとんどパフォーマンスの向上ではありません。そうしないでください。

算数に関してBIGINTは、少し速くなりますが、ほとんど気にならないかと思います。

于 2009-02-02T11:24:30.277 に答える
0

どの計算について話しているのか正確にはわかりませんが、それらがひどく複雑でない限り、いくつかの異なるテーブルでデータを検索するよりもはるかに高速です。可能であれば、db で計算を実行して (つまり、ストアド プロシージャを使用して)、アプリケーション レイヤー間のデータ トラフィックも最小限に抑えてください。

データの読み込みが速くなったとしても、非正規化されたデータを月に 1 回 (または四半期に 1 回) も更新しなければならないという考えはかなり怖いと思います。あなたはおそらくかなり迅速に仕事をこなすことができますが、システムを扱う次の人はどうでしょうか? データベース構造を学び、毎回更新する必要がある20個のテーブルのどれを覚えて、それを正しく行うように彼らに要求しますか? 非正規化でパフォーマンスが向上する可能性は、データが誤った情報で汚染されるリスクに対してあまり価値がないと思います。

于 2009-02-02T10:56:06.170 に答える