今天完成的事情：对于表的设计有分歧 韦杰提出两种方案

方案一：不设计冗余字段：

     优点：表结构符合清晰，一个表只描述一件事情，实体间关系用关联表描述，没有冗余字段或者冗余字段较少

     缺点：非常多的接口需要返回多表查询结果，但多表查询的语句复杂难写

方案二：

设计冗余字段：     优点：原来需要多表查询的地方，用简单的查询语句就能实现

     缺点：存在较多的冗余字段，删改查操作需要同时维护多个表的数据

选择方案：方案二

选择理由：选择方案二，也会有些接口需要返回多表查询的结果，把这些接口写好，我们也算是会写复杂的查询语句了

然而 我认为向后台操作的一些数据 冗余无所谓 因为只有后台操作  没有高并发

而前台 用户操作会产生的一些数据如 投资金额 冗余的话 维护很麻烦 维持数据一致也很麻烦 可能存在高并发 

简要介绍【聚金融】产品的类型，用户群体，主要提供的服务/功能：

聚金融一款P2P理财APP，但是在这里，我们把他做成一个WEB项目来实现。在聚金融里，只针对投资者提供理财及理财相关服务，不提供任何信贷及信贷相关服务。聚金融的所有债权都来自于线下的借贷关系。

模块/功能划分：

表结构设计：

总共有20张表，其中18张表分别在前后台展示，2张表不在前后台展示。这2张表为了方便执行业务

接口文档概述：

总共72个接口，其中前台25个接口，后台47个接口

明天计划的事情：最后对一次 发方案评审邮件
遇到的问题：对于冗余的考虑 询问老大 老大回答数据库的设计范式早已不适合现今互联网的发展了 

  对于冗余 处于性能考虑可以增加 后台的接口无需考虑 

收获：测试了一下不同类型 长度的限制 

varchar char必须指定长度 没有问题

int（M） M默认为11 是指定的显示宽度 然而指定为2 并没有什莫用 依旧可以显示1111111 只要不超过11位