下图是一个付费会员的列表，根据该产品需求，如何设计付费会员模块呢？
完成付费会员功能模块的开发，首先，熟悉需求，这四个字看起来简单，实际很难。
付费会员表中包含：搜索购买日期开始，搜索购买日期结束，购买日期，会员期限开始，会员期限结束，这五个字段，怎么命名，以及有什么关系，怎么建表，怎么计算业务。在看到需求时，这些在脑海中应该就有谱了。
第一个问题，内容相同含义不同的字段是否可以作为同一个字段。笔者可能比较喜欢精简，就认为购买日期=会员期限开始日期，那么这两个都作为startTime，即，queryStartTime，queryEndTime，startTime，endTime四个字段，可是当用户充值之后，且会员未到期，再次充值时，startTime会员期限开始时间不变，可是充值时间变了。两个概念就要有两个字段，千万不要作为一个字段图省事。这不仅与实际情况不符，而且业务逻辑计算会员期限的时候也容易混淆。虽然，我找产品确认了，购买日期不取最新一次购买日期，而是取未中断的最早一次购买日期，也就是会员期限的开始日期。
第二个问题，购买记录表与付费会员表存在冗余。购买记录表同样有购买日期，会员期限开始日期，会员期限结束日期，会员时长，这几个字段。既然与付费会员表有如此类似的内容，为何不合并为一个表呢？首先付费会员表存储付费会员信息，每个用户只有一条，是不是付费会员，根据用户id一查即可。而购买历史记录每个用户可以购买多次，当然不同于付费会员表。至于有冗余字段，我承认设计有一定问题，购买日期，会员期限开始日期，会员期限结束日期，会员时长，这四个字段应该只存在与购买历史记录里，然后通过用户id进行连接返回最新的一条充值记录，除了会员时长总和之外，就是付费会员表信息。也就是说，付费会员表只应该是购买历史记录表的一个视图。
因为多了付费会员表的四个冗余字段，导致业务逻辑出现冗余，两个service都需要计算一遍startTime和endTime，period。但也是没办法，只能说视图实现过于复杂，而且将来需求变化难以维护。新建一个付费会员表，实现简单，容易扩展，用于存储购买记录的统计结果。另外，付费会员表会员期限period是分为年，月，日三个字段进行存储的。如果像购买记录简单粗暴一个value，一个unit存储会员期限period，明显计算复杂，很难统计期限总和。
总之，冗余是可以容忍的为了查询速度，不同的含义最好新建不同的字段。优化空间也是存在的，像会员期限的开始时间，两张表中存的是一模一样的，购买记录表明显不应该有会员期限开始时间与结束时间，因为完全可以通过用户id连接从付费会员表中获取。目前来说，这两个字段在两个表中的值是一样的，会员期限开始时间=未中断第一次充值时间，会员期限结束时间=开始时间+会员期限总和。额，，忽然想到一个bug，期限总和=年+月+日，如果一次充值1年2月，那么，，，程序就有问题了。目前，是充实只能按月充值，是没问题的。不说了，改bug了。。。
