SQL нормализация данных / производительность

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 диапазона для suminsured [/ Править]

Список goods_types редко меняется, и большинство запросов на страхование будет включать товары на сумму менее 100 долларов США. В связи с этим я рассматривал возможность отмены нормализации с использованием таблиц в следующем формате (для всех значений от $ 0,00 до $ 100,00):

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

Денормализация этих данных должна быть проста в обслуживании, поскольку ставки обычно обновляются не чаще одного раза в месяц. Все запросы на значения> $ 100 всегда будут просматриваться в первичных таблицах и рассчитываться.

Мои вопросы:
1. Лучше ли мне хранить значения suminsured как DECIMAL (9,2) или как значение в центах, хранящееся в BIGINT?
2. Этот метод нормализации включает в себя сохранение 10 001 значений (от 0,00 до 100,00 долл. С шагом 0,01 долл.) В возможно 20 таблицах. Может ли это быть более эффективным, чем поиск процентов_премии и выполнение расчетов? - Или я должен придерживаться основных таблиц и сделать расчет?

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

Я не совсем уверен, о каких именно расчетах мы говорим, но если они не слишком неприятны, они, скорее всего, будут гораздо быстрее, чем искать данные в нескольких разных таблицах. если возможно, выполняйте вычисления в БД (т. е. используйте хранимые процедуры), чтобы минимизировать трафик данных между уровнями приложения.

и даже если загрузка данных будет быстрее, я думаю, что идея обновлять нормализованные данные так часто, как раз в месяц (или даже раз в квартал), довольно пугающая. Вы, вероятно, можете сделать работу довольно быстро, но как насчет следующего человека, который будет работать с системой? Вы бы потребовали от них узнать структуру БД, вспомнить, какие из 20 таблиц нужно обновлять каждый раз, и делать это правильно? я бы сказал, что возможный прирост производительности при ненормализации не будет стоить большого риска заражения данных неверной информацией.