I was told "Fields are expensive, records are cheap"

David,

Your comment: I would argue that since both are insurance policies, you can
use the survey model, and for each attribute of the policy, you create a
record in a table connected to the main policy record. For the different
types of insurance policy, you'll have a different set of variables, because
they are different types, but by storing each one as a row in a related
table, you've made your structure extensible so that you can model any type
of insurance policy. And if you like, you can use a single set of user
interface objects to work with and print all of them.

Response: I’ve seen this tried before and it was just too complicated. Not
only do you have the policy table, there is also the coverage master and line
specific coverage table. Then you have the objects that are being insured
tables (houses, warehouses, office buildings, bridges, coin collections,
people - work comp, people’s honesty in bonds, and and on).

Then you have all of the transactions that apply to a policy such as
on-line rating, policy issuance, automatic cancellation for non-pay,
automatic reinstatement for payment received before the cut off date, offer
to renew, automatic renewal, automatic non-renew. Then you have the
sequential endorsement (changes to the policy), that can be done at any level
(policy, coverage, limits, object being insured and the limits on those
specific objects). Then you have out of sequence endorsements where you have
to back off exiting endorsement to apply an endorsement from the past, and
then reapply the backed of endorsement taking into account that the out of
sequence endorsement may have removed the insurable object that a subsequent
endorsement want to change. When you add all of these transactions to all of
the different data, it becomes very very complicated to have a table drive
database.

Maybe there are more recently developed systems that take this approach. I
actually think it is actually a pretty good approach, just very machine
intensive. But with the faster CPU of recent times, it is much more
feasible.

Now that I think about it, one of the systems that I worked on used a
simplified version of what you are suggesting to enable the users to extend
their policy, coverage, and insurable object databases.


Dennis