这次教训比较深刻，磨刀不误砍柴工也是这个道理，最大的体会就是：
相比较技术而言，解决问题的思想和方式更为重要
。
在开发一项公司活动产品的过程中，我因为建表太过肤浅，不规范，导致后期开发的过程中，代码越来越臃肿，各项判断循环嵌套，极难维护和再拓展。我下来请教了同事，咨询了几位朋友，最后得出以下四点心得，发出来，时刻提醒自己：
1.根据实际需要解决的问题去分析该问题存在几个主体，一次来确定需要几个
表
，表之间的关系是什么。
例子：邀请人，被邀请人，团队。
a通过分享链接，b点击链接注册参与活动。a是邀请人，b是被邀请人，a和b共同组成一个团队大A，该团队的负责人是a。
这个例子中出现了3个主体：a、b、A，其中A是a和b组成的组织型主体，虽然在现实生活中不具有实体，但A也有自己独有的属性，所以也必须单独作为一个主体。
2.根据这些主体具有的主要属性，以及实际问题需要对这些主体做哪些数据处理的操作（需求分析），这两点来判断这些主体（表）都需要哪些具备哪些
字段
。
3.给每个字段设置
数据类型
和是否为空时，需要细化具体分析，预测做该字段的数据处理是，涉及到哪些操作，如何设置数据类型，才能实现更高效的开发。
第1、2、3步需要反复推敲，直至打通每一个环节，才能进行后续的代码开发。
4.在后端代码的开发初期，时刻反思数据库设计是否合理，数据表是否合理，数据类型是否合理。如果改动，是否会影响到其他的逻辑操作。这一步需要兼顾数据库稳定和高效。
我后来又仔细分析了这个项目，重新建表，总共需要3张表，20个字段，但是我错误地把他们综合到一张表里去了，才6个字段，这也是导致我代码极其臃肿丑陋的原因。
修改后的表：
团队表
|
团队id
|
团队名称
|
推荐人id
|
成员数量
|
推荐人表
|
推荐人id
|
姓名
|
性别
|
电话
|
时间
|
团队id
|
验光状态
|
是否满团
|
被推荐人表
|
被推荐人id
|
姓名
|
性别
|
电话
|
推荐人id
|
时间
|
验光状态
|
一开始设计错误的表：
|
id
|
被推荐人电话
|
推荐人电话
|
时间
|
姓名
|
性别
|
密码
|
验光状态
|