SQL數據規範化/性能

我正在爲保險行業開發一個Web API，並試圖找出合適的保險報價數據結構。SQL數據規範化/性能

該數據庫已經包含了一個「評分」表基本上是：

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 - 爲suminsured [/編輯] 4範圍

的goods_types列表很少發生變化，大多數保險查詢將涉及價值低於100美元的商品。正因爲如此，我正在考慮（通過到$ 100.00從$ 0.00的所有值）使用以下格式表去正火：

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

Denormalising這個數據應該是易於維護的利率一般只更新一次每月最多。所有價值> 100美元的請求將始終在主表中查找並計算。

我的問題是：
1.我最好將存儲的值作爲DECIMAL（9,2）或存儲在BIGINT中的分值？
2.此解除歸一化方法涉及在可能的20個表格中存儲10,001個值（$ 0.00到$ 100.00以$ 0.01爲增量）。這可能比查找percent_premium和執行計算更有效嗎？ - 或者我應該堅持主表並進行計算？

來源

2009-02-02 John

請勿創建新表格。您已經有上貨，最小值和最大值的指數，所以這個SQL（知名商品，其價值）：

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

將efficently使用索引。

你正在尋找的數據類型是smallmoney。用它。

來源

2009-02-02 11:11:35 dmajkic

我不完全確定我們正在談論的計算是什麼，但除非它們非常複雜，否則它們比在幾個不同的表中查找數據要快得多。如果可能的話，在數據庫中執行計算（即使用存儲過程）以最小化應用程序層之間的數據流量。

即使數據加載速度更快，我認爲必須每月更新一次（甚至每季度一次）更新非標準化數據的想法非常可怕。你可能很快就能完成這項工作，但下一個處理系統的人又該如何呢？你是否需要他們學習db結構，記住每次需要更新的20個表中的哪一個，並且正確地執行它？我會說在去歸一化方面可能的性能提升對於以不正確的信息來污染數據的風險並不值得。

來源

2009-02-02 10:56:06

感謝您的回答。對於DECIMAL（9,2）中使用的存儲幣種值和使用BIGINT的幣值，您有任何想法嗎？ – John 2009-02-02 11:00:43

其實，我不知道。我不太瞭解數據庫的具體情況，以瞭解哪個最有效。不要相信我;）我最初的想法是，整數更快，如果你乘，但我不知道bigint如何反應分裂 - 取決於你如何存儲結果，你可能會失去數據。 – 2009-02-02 11:44:12

您建議的計劃將使用binary search10001行而不是3或4。

這幾乎不是性能改進，不這樣做。

至於算術，BIGINT會稍微快一點，以爲我認爲你幾乎不會注意到這一點。

來源

2009-02-02 11:24:30 Quassnoi

SQL數據規範化/性能

回答

相關問題