关于续保的数据结构方面的问题 - 金融行业 - ITPUB论坛－专业的IT技术社区

wangjia

保证续保的保单在第二年及以后的续保时，为客户方便，要求保单号保持不变，但保单号是保单表的主键，不能让两条记录同时存在。
一种方法将续保记录的内容修改后保存在保单表，原记录删除后保存在一个备份表。但该方法对历史统计报表带来较大影响，做历史同期比较就全乱了。如果同时查备份表，不但修改工作很大，而且会严重影响效率。
另一种方法是只保留原有记录，只是将保费变化、止保日期进行修改后保存。但也有一些问题。
请问各位在项目中是如何处理该类问题的？请指教。
保证续保的产品一般都是一年期的产品，但在一定时间内可以自动续保。从实际上说，一张保单期满终止，要发通知给客户的，由客户确认是否续保，并确认相关信息是否发生变化，同意续保之后就是换了新的一张保单，所以一定要换掉保单号码才有可以。其实对于客户来说，只要有身份证号码就可以找得到公司内所有的保单，，从CC的查询记录来看，也是通过身份证和姓名甚至代理人查询信息的记录比较多，除非手上拿着保单，否则没人会去记号码，所以保单号码对客户没什么大意义，换与不换关系不大，换掉只要做好关联就可以了。
另外通常做法就是当这个险种是长期险，续保问题就成了续期问题，处理就没什么特殊的了。
我见过很多公司的系统都是这样处理的。也有两种方式都用到的
谢谢Barbalala。
其实原来也想用你说的换号的方法，但业务很强硬，一时难以说通。可以考虑用长期险的方式处理，我再细想想。
其实业务部门的要求也不是没有道理，要是之前的数据模型就考虑到这样的问题，policy主表中，保单期数也是key，并在各个模块都有相关处理。用户的需求就可以很方便的实现。但现在是在已有的系统上打补丁就要尽量少调整，减少结构调整带来的bug。这样上述办法就是最好的了，如果改用长期险的做法，要小心产品设置对财务，精算，理赔部分的影响，毕竟这个产品在上报保监会数据时，在财务处理时，还是短险
BTW，在保险公司里做IT很多时候，不能只关注技术或者解决方案，一定要同业务部门的主管及主要用户保持好关系，要用最简单通俗的方式让他们理解IT系统调整的困难，培养一批优质用户，有了他们的支持才能过得舒服点，不然就是挨踢的，累得要死要活，也捞不着好 。。。。。。
呵呵，有的时候还可以利用一下业务部门之间的矛盾，比如客服和市场，客服提出的需求如果你不喜欢，可以看看会不会对市场部造成影响，如果增加了市场部的工作量，就把这个球踢给市场部，让他们对反对客服的需求，等他们扯皮完了，估计需求也差不多黄了。哈哈，我原来总是这么干的，少好多活的阿
下午又讨论了一通，觉得还是先维持目前的做法，不太敢大动。 ：（。但历史报表通过扎账表或实收保费表去统计。再有些查询要求通过联查备份表实现，虽然会损失些性能。