Insurance Poisoning

One of the reasons I seem to be better off serving one master is the very nature of the app I’ve written. Master-detail normalization scenarios are problematic. Interestingly, reality seldom presents models going beyond the binary level of abstraction. Indeed, the few, such as inventory Bills of Material, invite self-referencing and may be accommodated, regardless of complexity, by a master and detail file.

Such is the lay of the land if you’re making furniture. Property insurance is another matter. My very successful and quite well known model among mutual companies in NC involves a master and eight detail files. On top of that, I maintain 5 iterations of that construct. Thank God I’m able to address Current, Held, History, Archive and Quote iterations of a policy instance with one set of screen forms and rating programs using macro-substitution.

Perhaps you’re getting some insight into support of a half dozen, much less one of these systems. BTW, I’ve not abandoned these unfortunates; I’m merely extorting funds.

Multiply the complexity of the app inversely by the total illiteracy demonstrated by some of my customers and you get a very large number.

The prevailing thought on management of master and detail files is use of a surrogate key. Indeed, much conventional wisdom on the subject is to be found in books describing apps and processes written by companies which no longer exist. I wish to point out the obvious fact that I fucking use them and I damn well, not to mention my apps, remain.

A surrogate key is a reliably unique string of letters and numbers assigned to the master and detail records. Prior, important things like Order and Policy numbers were used to relate them. Problem is there are legit reasons to change them. Then you must invoke Referential Integrity logic to ensure the detail records are updated, lest they be lost. With a surrogate key the only RI logic required is for a cascading delete.

Needless to say, my VFP apps reflect best practices. OTOH my legacy apps are nothing but balls and chains.

Among the most significant improvements to my app is the Held Policy file. The aim is to capture to the History file a copy of what a policy looked like prior to any significant change. However, a policy being re-written at renewal often undergoes many changes before being finalized. We only need one copy of what it looked like before in History. Keeping that copy in the Held file until all changes have been made results in a very accurate and much less populous History file.

Auditors love me and with good reason.