Pergunta

Eu estou trabalhando em uma API web para o setor de seguros e tentando descobrir uma estrutura de dados adequada para a citação de seguro.

O banco de dados já contém uma tabela "classificações" que é basicamente:

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]

[editar] Cada tipo de produtos tem, tipicamente, 3 - 4 intervalos para suminsured [/ Edit]

A lista de goods_types raramente muda e a maioria das consultas para o seguro vai envolver a pena bens menos de US $ 100. Devido a isso, eu estava pensando de-normalizar o uso de tabelas no seguinte formato (para todos os valores de $ 0,00 até US $ 100,00):

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

desnormalizar esses dados devem ser de fácil manutenção como as taxas são geralmente atualizados apenas uma vez por mês, no máximo. Todos os pedidos de valores> $ 100 será sempre olhou para cima nas tabelas primárias e calculado.

A minha pergunta (s) são:
1. Estou melhor fora de armazenar os valores suminsured como decimal (9,2) ou como um valor em centavos armazenado em um BIGINT
2. Este método de normalização-envolve armazenar valores 10.001 ($ 0,00 a $ 100,00 em incrementos de $ 0,01) em 20 possivelmente tabelas. É este tende a ser mais eficiente do que procurar o percent_premium e realizar um cálculo? - Ou devo ficar com as principais tabelas e fazer o cálculo

?
Foi útil?

Solução

Não crie novas tabelas. Você já tem um índice em bens, valores mínimo e máximo, de modo que este sql para (bens conhecidos e seu valor):

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

usará seu índice efficently.

O tipo de dados que você está procurando é smallmoney . Usá-lo.

Outras dicas

O plano sugere usará um binary search em linhas 10001 em vez de 3 ou 4.

É quase uma melhoria de desempenho, não faça isso.

Como para aritmética, BIGINT será um pouco mais rápido, pensei que eu acho que dificilmente você vai notar isso.

Eu não sou inteiramente certo exatamente o que os cálculos que estamos a falar, mas a menos que sejam desagradavelmente complicado, eles vão mais do que provável ser muito mais rápido do que procurar dados em várias tabelas diferentes. se possível, realizar os cálculos no db (isto é usar procedimentos armazenado) para minimizar o tráfego de dados entre as camadas de aplicação excessivamente.

e mesmo que o carregamento de dados seria mais rápido, eu acho que a idéia de ter que atualizar os dados de-normalizados tão frequentemente quanto uma vez por mês (ou até mesmo uma vez por trimestre) é muito assustador. você provavelmente pode fazer o trabalho muito rapidamente, mas que sobre a próxima pessoa lidar com o sistema? se você precisar deles para aprender a estrutura de db, lembre-se que dos 20-algumas tabelas que precisam ser atualizados a cada vez, e fazê-lo corretamente? Eu diria que o ganho de desempenho possível em de-normalizando não vai valer muito para o risco de contaminar os dados com informações incorretas.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top