If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
Thread Tools | Display Modes |
#16
|
|||
|
|||
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 |
Thread Tools | |
Display Modes | |
|
|