Необходимо разработать базу данных SQL Server 2005 для хранения страховых ставок

Всем доброго вечера,

Клиент попросил меня разработать веб-приложение как часть его существующего сайта, построенного на ASP.net 3.5, которое позволит его брокерам генерировать котировки для потенциальных групп клиентов. Такие котировки должны быть получены с использованием таблиц курсов, хранящихся в базе данных SQL Server 2005.

Структура таблицы следующая:

[dbo].[PlanRates](
[AgeCategory] [int] NULL,
[IndustryType] [int] NULL,
[CoverageType] [int] NULL,
[PlanDeductible] [float] NULL,
[InpatientBenefit] [float] NULL,
[Rate] [float] NULL,
[OPMD15Copay] [float] NULL,
[OPMD25Copay] [float] NULL

Вопрос: Предполагая, что я использую проверку страницы в веб-приложении для проверки входных данных на соответствие бизнес-логике, ожидаете ли вы возникновения проблем, связанных с тем, что веб-приложение возвращает котировку с использованием приведенного выше макета таблицы базы данных? Если да, можете ли вы предложить лучший способ структурировать мою таблицу?

Бонус достается любому, кто запрограммировал веб-системы котировок страховых услуг.

Большое спасибо за вашу помощь и руководство.


sql-server-2005 asp.net-3.5
person SidC    schedule 21.10.2009    source источник

Ответы (3)


arrow_upward
3
arrow_downward

Я бы определенно добавил суррогатный первичный ключ, например. PlanRatesID INT IDENTITY(1,1), чтобы сделать каждую запись уникальной.

Во-вторых, я бы подумал, что поля «PlanDeductible», «InpatientBenefit», «Rate» являются денежными значениями, поэтому я бы определенно сделал их типа DECIMAL, а не FLOAT. Число с плавающей запятой не очень точное и может привести к ошибкам округления. Для DECIMAL вам также необходимо указать количество значащих цифр до и после десятичной точки, например. DECIMAL(12,3) или что-то в этом роде.

Вот об этом! :)

person marc_s    schedule 21.10.2009
comment
Полностью согласен с использованием типов данных с фиксированной точностью. - person Gratzy; 21.10.2009
comment
Отличная идея с суррогатным первичным ключом! Это была моя настоящая боль :) - person SidC; 21.10.2009

arrow_upward
2
arrow_downward

Я бы предложил использовать параметризованные запросы для сохранения ваших данных для защиты от SQL-инъекций.

ИЗМЕНИТЬ

Это выглядит как

[AgeCategory] [int] NULL,
[IndustryType] [int] NULL,
[CoverageType] [int] NULL,

Вероятно, это внешние ключи, если это так, вы можете не захотеть делать их нулевыми.

person Gratzy    schedule 21.10.2009
comment
Очень дельный совет! Спасибо!! - person SidC; 21.10.2009

arrow_upward
1
arrow_downward

Категория, типы и ставки, допускающие значение NULL?

Столбцы категорий и типов являются полями поиска в других таблицах, в которых хранится дополнительная информация для каждого типа.

Вы должны проверить, какие из столбцов действительно допускают значение NULL, и определить, как поступать со значениями NULL.

Поскольку ставки могут меняться, вам также следует учитывать диапазон дат в таблице (ValidFrom, ValidTo DATETIME) или иметь таблицу истории, связанную с таблицей выше, чтобы убедиться, что прошлые расчеты ставок могут быть повторены. (Может быть юридическим/финансовым требованием)

person devio    schedule 21.10.2009