Question

我正在为保险行业开发一个网络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))

对这些数据进行非规范化应易于维护，因为费率通常最多每月更新一次。所有价值> 100美元的请求将始终在主表中查找并计算。

我的问题是：
1.我最好将总保险值存储为DECIMAL（9,2）或存储在BIGINT中的分数值吗？
2.这种去规范化方法涉及在可能的20个表中存储10,001个值（$ 0.00到$ 100.00，以$ 0.01为增量）。这可能比查找percent_premium和执行计算更有效吗？ - 或者我应该坚持主表并进行计算？

Answer 1

不要创建新表。你已经有货物，最小值和最大值的索引，所以这个sql（已知商品及其价值）：

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

将有效地使用您的索引。

您要查找的数据类型是 smallmoney 。使用它。

Answer 2

您建议的计划将使用binary search行10001代替3或4。

这不是性能提升，不这样做。

至于算术，BIGINT会稍快一些，我想你几乎不会注意到这一点。

Answer 3

我不完全确定我们正在谈论的是什么计算，但除非它们令人讨厌地复杂化，否则它们可能比在几个不同的表中查找数据更快。如果可能，在db中执行计算（即使用存储过程），以最小化应用程序层之间的数据流量。

即使数据加载速度更快，我认为必须每月（甚至每季度一次）更新非规范化数据的想法非常可怕。你可以很快完成这项工作，但下一个处理系统的人呢？你是否需要他们学习数据库结构，记住每次需要更新的20个表中的哪一个，并正确地执行？我想说，对于使用不正确的信息污染数据的风险，去标准化可能带来的性能提升不会太大。

SQL数据规范化/性能

3 个答案: