一、crm需求分析
""" 为什么开发这个crm？ 我需要把这个作为一个通用的crm， 开发这个项目要解决企业的痛点 几个角色，销售，学生，讲师，老板， 从场景梳理出来需求
解决一个销售人员的痛点： 1，聊得多了记不住 2，出现两个销售人员抢单的问题， 3，辞职了怎么办？学生都带走了， 需求： 1，存储学生信息， 2，办理报名手续， 3，跟进记录，一个学生需要跟进多次，所以是一个一对多的关系，需要分表 4，各种维度查询学生信息， 解决学生的管理的痛点： 1，学生要培训，考试，交试卷，要做阶段性的考核，检查，对学生进行管理， 2，最好是每一个学生的培训都有记录， 3，每一个学生的业绩最后有问题，都是有原因的， 4，学生都是比较懒的，学生时间是不固定的，需要监督，需要考核
在线教育的痛点，时间问题（学生时间不固定这是劣势），空间问题（哪里都可以学这是优势），
需求： 1，交作业
2，查成绩，
3，请假
4，我的合同 5，我的推荐，推荐别人来加入， 6，投诉建议， 解决讲师的痛点： 1，有一个评估 2，跟踪每一个学生的情况，看看学生的学习效果， 需求： 1，点名，
2，查看成绩， 3，创建上课记录， 4，查看成绩，考核结果，
5，问卷调查，问问学生的感受
解决老板的痛点： 1，有多少学生，学生的来源，分析这个来源是否产生了学生，是否还需要继续投入这个渠道，比如百度竞价排名，可以是招商， 2，每个学生业绩怎么样， 3，老板需要看报表，数据都是零散的，不利于分析，聚集起来就利于分析，就知道该往哪一个方向发展， 需求： 1，销售报表分析 2，教学质量分析， """
二、考虑系统架构
"""
考虑系统架构 架构设计需要考虑的因素： 1，用户人群，是怎么样的，这个crm主要面对企业内部用户，所以对于各方面的要求不是很高， 页面不需要太炫，甚至安全程度也可以适当降低，公司一般要求越快开发出来越好， 2，用户量，针对企业内部用户量不多，如果是微博，每天上亿用户，用户量特别大，使用django就不合适了，需要使用tornado，
django天生就是做内容管理的，就是通过不同形式把内容展现出来， 这个crm就特别适合django做，微博会有高并发的问题， 3，业务场景，业务比较简单，就是页面点击什么，然后就从数据库查询就可以了，没有复杂的后端逻辑，就是增删改查，
所以要求是什么？
1，安全性要求不高
2，美观性要求不高
3，越快开发出来越好
4，不需要高并发
5，不需要复杂逻辑，就是查询
用到的技术： 1，django 2，jQuery，本质就是对原生js的封装， 3，bootstrap 做完这个项目之后，涉及到数据的curd操作，你就都会了，直接就能用， """
三、设计表结构
""" 需求分析完了，架构设计完成，下一步就是设计表结构， 大部分的交互都是和数据库交互，必须要确定好表结构，否则后续会出现问题，会有很多的坑，不断的出现坑，就填不过来了， 但是肯定会有问题，因为业务是复杂的，多变的，牛逼的开发，架构师，就能把路铺好，提前想到一些坑， 通用相关的表： 1，账号表，是否要用django自带的，要注意，
这是通用的，django提供了这种通用的东西，有自带的认证模块，
2，角色表，
name，
3，菜单表， 销售相关的表： 1，客户信息表：没有报名的是学生，报名的是学生，报名的学生要到报名表，
name，可以是空，blank=True，null =True
qq，这个需要唯一标识，不能为空，unique=True，
qq_name，
phone，可以为空，
source_choices = ((0,"转介绍"),
(1,"qq群"),
(2,"百度")... )
source，SmallIntegerField，使用这个可以减少存储的空间，
referral_from，推荐人
consult_course，咨询了什么课程
content，咨询的内容，Text类型，
tag，多对多，一个标签可以给多个人，一个人可以多个标签，
2，学生跟进表，
customer，跟进那个客户
content，跟进内容
consultant，谁跟进的，外键，账户表，
data，跟进时间
intention_choice = ((),())
intention，跟进意向
3，报名表，需要一个学生表，一个学生可能有多条报名信息，可以报多个课程，
customer 关联学生表
class，报了什么班
consult，销售是谁
contact_aggres，布尔类型，学生同意
contact_approve，合同审核，销售审核，只有这两个都是True，才是合同生效了，
data_time，
联合唯一，学生和班级，
4，缴费表，
customer，关联客户表
amount，金额，
course，关联课程表，
data，
5，标签表， name，
讲师相关的表： 1，课程表-----这是固定的
name
price,PositiveSmallIntegerField,正整数，
period
outline，大纲
2，班级表-----一个班级只能是一个课程，
course，课程
semester，学期
teacher，老师，
branch，校区，所有的choice字段都可以拓展成为一个表，
type_choice = ((),())
type，面授，还是网络
state_data，开班日期
end_data。
class_Meta:
联合唯一，校区，课程，加起来联合唯一，
3，上课记录表，一个课程每天都要有记录，一对多的，因为有很多的学生，
from_class，来自哪一个班级
day_num，第几天，一天一次上课记录，
teacher，老师
has_homework，是否有作业
homework_title，可以为空，
homework_content,可以为空，
out_line，本节的大纲
data，
联合唯一，班级和第几天，
4，学习记录表，------一对多，不能是和上课记录多对多，你同一个时间只能听一个上课记录，
student，关联学生报名表，
course_record，关联上课记录表
attendance_choice,出席是否
attendance
score_choice，分数，
score，
班级表---->上课记录表---->学习记录表
5，校区
name
addr。
核心的表就是这些， """
##################
角色和需求 1，销售人员， 1.1，要对学生进行维护，可以对学生进行查看，新增，删除，修改，跟进等操作 代码上的要求： 增删查改各使用一个页面，然后根据每一个表的配置来控制，展示的字段，筛选字典，查询字段，批量操作，要求是可配置的， 1.2，最复杂的是学生查看页面，有查询，有筛选，有批量，有表头，有列表，有分页， 1.3，要有学生报名的业务， 1.4，学生池的概念，可以把没有成交可能的放入学生池，也可以把你认为有可能成交的学生拉入自己的名下， 2，讲师 1.1，要批量生成上课记录，对学生考勤 1.2，每天的作业成绩需要录入 3，学生 1.1，要交作业， 4，老板 要看报表， 5，登陆，注册，菜单展示，权限控制，
########################