Re: Insurance data models...any tips on good starting point?

On Jul 10, 6:33 pm, Gene Wirchenko <ge..._at_ocis.net> wrote:
> aai_jj <jjohn..._at_grafikchaos.com> wrote:
> >We have a client that has the typical online quote generator but is
> >looking to revamp that process and tie it in with other services he
> >can sell to other insurance clients. The application is still in its
> >infancy but could have the potential of blowing up in our face if we
> >don't plan accordingly.
>
> >The old website used a fairly simple RDB with a lot of array
> >manipulation done by the developers, but we'd like to make it a little
> >more object-oriented, maybe even consider an EAV modeling approach to
> >allow for the growth.
>
>      Why not try Russian roulette?  There is only a one in six chance
> of you shooting yourself.  It is more likely that EAV that will be a
> problem.
>
> >Are there any insurance data models out there to start from or is
> >anybody willing to share their experience on similar projects?
>
> >Any thoughts or direction would be greatly appreciated.
>
>      EAV is not a good idea.
>
> Sincerely,
>
> Gene Wirchenko
>
> Computerese Irregular Verb Conjugation:
>      I have preferences.
>      You have biases.
>      He/She has prejudices.

Thanks to the previous posters. Secretly I'm pretty much in agreement with all of you that EAV in theory sounds good but the cost of just getting our development team to swallow the little red pill and jump down that rabbit hole and become 70% efficient and by the end have a 100% successful application is going to be nigh impossible. Our team is more comfortable with straight RDBs and MySQL so in my mind it would make sense to keep it simple and avoid the headache of trying to CRUD EAV across so many tables.

Right now the application doesn't need to be the most flexible forward thinking db schema out there as the application as of right now is only meant to service one state. But what if it becomes popular and opens up to 10 or 20 states? Our main concern is that how are we going to manage the details/rates of an Insurance Plan when 2 or more states have the same Carrier and Plan but the Rates are different based upon their attributes (Smoking, Number of Dependents, Single/Family, M/F, etc.). Has anybody dealt with a similar situation? We definitely don't want to end up with a database with an ungodly amount of fields with null values but would like it to have some flexibility for growth.

Thanks again. Received on Fri Jul 11 2008 - 15:50:29 CEST