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))

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

我的问题是：
1. 我最好将总和值存储为 DECIMAL(9,2) 还是存储在 BIGINT 中的美分值？
2. 这种反规范化方法涉及在可能的 20 个表中存储 10,001 个值（0.00 美元到 100.00 美元，增量为 0.01 美元）。这可能比查找 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

您建议的计划将使用 a binary searchon 10001rows 而不是3or 4。

这几乎不是性能改进，不要那样做。

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

于 2009-02-02T11:24:30.277 回答
0

我不完全确定我们在谈论什么计算，但除非它们非常复杂，否则它们很可能比在几个不同的表中查找数据要快得多。如果可能，请在数据库中执行计算（即使用存储过程）以最小化应用程序层之间的数据流量。

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

于 2009-02-02T10:56:06.170 回答