python2.0_day19_后台数据库设计思路

from django.db import models

# Create your models here.

from django.contrib.auth.models import User

course_type_choices = ((‘online‘,u‘网络班‘),                       (‘offline_weekend‘,u‘面授班(周末)‘),                       (‘offline_fulltime‘,u‘面授班(脱产)‘),                        )

# 校区表class School(models.Model):    name = models.CharField(max_length=128,unique=True) # unique=True 的作用是返回给前端或者调用的时候不是一个对象,而是一个具体的数据,能区别他是谁    city = models.CharField(max_length=64)    addr = models.CharField(max_length=128)

    def __str__(self):        return self.name

# 基本用户表class UserProfile(models.Model):    # user = models.ForeignKey(User) # 我们想使用Django自带的User进行验证,但是不能用ForeignKey(),因为不能让一个内部账户对应多个用户    user = models.OneToOneField(User,verbose_name=u"关联用户")    # 使用Django models里的OneToOneField(),实现限制一个内部账户对应一个用户,                                        # 只是在Django admin层面中实现了1对1,mysql本身是不具有实现1对1外键的.                                        # 底层用的ForeignKey()    name = models.CharField(u"姓名",max_length=64) # u"姓名"这个是在admin后台管理时显示的字段名也可以用verbose_name=u‘姓名‘,这两个的区别是,verbose_name可以用在任何字段里,而u"姓名"不能用于ForeignKey()等特殊字段,用户名,最大长度64.    school = models.ForeignKey(School)    # 一个用户最少要属于一个中心    def __str__(self):        return "%s(%s)"%(self.name,self.school)    class Meta:        verbose_name = u"用户"         # 单数形势显示verbose_name的意思很简单,就是给你的模型类起一个更可读的名字        verbose_name_plural = u"用户"  # 复数形势显示,如果不指定Django会自动在模型名称后加一个’s’,比如默认显示成 User profiles

# 定义课程表class Course(models.Model):    name = models.CharField(max_length=64,unique=True)    online_price = models.IntegerField()    offline_price = models.IntegerField()    inroduction = models.TextField() #课程介绍字段

    def __str__(self):        return self.name

# 写一个班级表class ClassList(models.Model):    course = models.ForeignKey(Course,verbose_name=u"课程")    semester = models.IntegerField(verbose_name=u"学期")

    teachers  = models.ManyToManyField(UserProfile)    start_date = models.DateField()    graudate_date = models.DateField()    # 创建班级时要分网络版和面授班(脱产\周末)    # 我们在创建客户信息表时,就选择了咨询的课程类型.这里又用到这个课程类型.所以是不是要在这里又重新写一遍.但是我如果不想写呢?    # 不想写就把 在客户信息表中写的 course_type_choices ,放到class外面,这样就是全局变量,多个class都可以使用    course_type = models.CharField(max_length=64,choices=course_type_choices)

    def __str__(self):        return "%s(%s)(%s)"%(self.course.name,self.course_type,self.semester)

    class Meta:        unique_together = (‘course‘,‘semester‘,‘course_type‘)

# 客户表,存储客户咨询信息class Customer(models.Model):    qq = models.CharField(max_length=64,unique=True)    name = models.CharField(max_length=32,blank=True,null=True)    # phone = models.IntegerField() #不能用IntegerField,不够长最长10位    phone = models.BigIntegerField(blank=True,null=True) #blank=True 允许在admin层面为空,null在数据库层面允许为空    course = models.ForeignKey(Course)    # 1.课程类型越来越多(每一个课程都有网络和面授) 2.动态更新课程信息 鉴于这两个条件,课程记录应该单独做一张表    # course_type_choices = ((‘online‘,u‘网络班‘),    #                        (‘offline_weekend‘,u‘面授班(周末)‘)    #                        (‘offline_fulltime‘,u‘面授班(脱产)‘)    #                         )    course_type = models.CharField(max_length=64,choices=course_type_choices,default=‘offline_weekend‘)  # 定义咨询类型字段,choices 这里只是在Django admin层面变成可选的                                                                                            # 对于Django API 不回默认选择框    consult_memo = models.TextField()    # 搞一个变量,如下,来源选择列表    source_type_choices = ((‘qq‘,u‘qq群‘),                           (‘referral‘,u"内部转介绍"),                           (‘51cto‘,u"51cto"),                           (‘agent‘,u"招生代理"),                           (‘others‘,u‘其它‘)                            )    source_type = models.CharField(choices=source_type_choices,max_length=128,default=‘qq‘)    # 学员转介绍,创建一个字段,关联本表中某一个客户,知识点关联自己,重点在于ForeignKey(‘self‘),是加引号的self,因为自己还没被创建,或者写自己的表名ForeignKey(‘Customer‘)    referral_from = models.ForeignKey(‘self‘,blank=True,null=True,related_name=‘referral_who‘)    status_choieses = ((‘signed‘,u"已报名"),                       (‘unregistered‘,u"未报名"),                       (‘graduated‘,u"已毕业"),                       (‘drop-off‘,u"退学")                        )    status = models.CharField(max_length=64,choices=status_choieses)    consultant = models.ForeignKey(‘UserProfile‘,verbose_name=u"课程顾问") # verbose_name的作用是用form类或者admin后台显示中文    class_list = models.ManyToManyField(‘ClassList‘,blank=True) # 如果报名,可以关联班级表,多对多    date = models.DateField(u"咨询日期",auto_now_add=True) #默认填入当前日期

    def __str__(self):        return "%s(%s)"%(self.qq,self.name)

# 客户追踪记录# 首先我们相当的是记录到客户表汇总.但是一个客户可能有多条咨询记录,我们在用户表中只有一个字段是记录咨询记录的.我们肯定要有多条记录,所以要专门创建一个表来存储咨询记录class CustomerTrackRecord(models.Model):    customer = models.ForeignKey(Customer) #关联客户    track_record = models.TextField(u"跟踪记录")    track_date = models.DateField()    follower = models.ForeignKey(UserProfile)   #跟踪人    status_choices = ((1,u"近期无报名计划"),                      (2,u"2个月内报名"),                      (3,u"1个月内报名"),                      (4,u"2周内报名"),                      (5,u"1周内报名"),                      (6,u"2天内报名"),                      (7,u"已报名"),                        )    status = models.IntegerField(choices=status_choices,help_text=u"选择客户此时的状态")  # 咨询的结果状态    def __str__(self):        return self.customer

# 班级上课记录表# 首先我们在客户表中创建了客户与班级的关联,每一个班级可以反向查找有都少学生# 但是每一个班级又有很多天的课程,是不是应该创建一个上课表,表中把班级关联起来.然后把班级里的每一个学员关联起来记录这个学生每天的学习情况class CourseRecord(models.Model):    class_obj = models.ForeignKey(ClassList)    day_num = models.IntegerField(u"第几节课") #显示的时候"第几节课"    course_date = models.DateField(auto_now_add=True,verbose_name=u"上课时间")    teacher = models.ForeignKey(UserProfile)  # 讲师    # students = models.ManyToManyField(Customer)  # 这个字段用manytomany的方式体现学员和上课记录的关系.那么问题来了,我们知道manytomany定义后会产生一张关系表.                                                # 那么我们怎么体现学生是不是迟到呢?你在创建的时候怎么确认哪些人来哪些人没来.你可以说点名后创建记录,但是你能体现迟到不迟到吗.当然不可以.                                                # 理想的方式是这里不用manytomany的方式关联students,而是另外创建一个学习记录表.学习记录可以为每一个学员关联班级上课记录表,所以这里注释掉    def __str__(self):        return "%s,%s"%(self.class_obj,self.day_num)

    class Meta:        unique_together = (‘class_obj‘,‘day_num‘)  # 同一个班级不能出现同一天的课程2次

# 学员的学习记录表,签到状态,成绩class StudyRecord(models.Model):    student = models.ForeignKey(Customer)    record_choices = ((‘checked‘,u"已签到"),                      (‘late‘,u"迟到"),                      (‘noshow‘,u"缺勤"),                      (‘leave_early‘,u"早退"),                        )    record = models.CharField(u"状态",choices = record_choices,max_length=64)    #此处需要注意,当我们在html模版文件中或者在admin后台管理显示记录时,record显示的是英文,而不是选项里的中文.    # 如果想显示中文在html模版文件中就需要写成 obj.get_record_display,而在admin中定义表admin时,get_record_display    #关联班级上课记录表    course_record = models.ForeignKey(CourseRecord)    score_choices = ((100,‘A+‘),                     (90,‘A‘),                     (85,‘B+‘),                     (80,‘B‘),                     (70,‘B-‘),                     (60,‘C+‘),                     (50,‘C‘),                     (40,‘C-‘),                     (0,‘D‘),                     (-1,‘N/A‘),                     (-100,‘COPY‘),                     (-1000,‘FAIL‘),                    )    score = models.IntegerField(u"本节成绩",choices=score_choices,default=-1)    date = models.DateField()    note = models.CharField(u"备注",max_length=255,blank=True,null=True)

    def __str__(self):        return "%s,%s,%s,%s"%(self.course_record,self.student,self.record)

# 对于admin后台显示问题的总结:# 1.对于本身这个表在后台管理界面时,每张表都是英文表名,如果想显示成中文就需要在表类中定义如下:# class Meta:#     verbose_name = u"用户"         # 单数形势显示verbose_name的意思很简单,就是给你的模型类起一个更可读的名字#     verbose_name_plural = u"用户"  # 复数形势显示,如果不指定Django会自动在模型名称后加一个’s’,比如默认显示成 User profiles

# 2.1 默认表中的记录显示的是对象.可以定义#         def __str__(self):#             return "%s,%s"%(self.name,self.school)# 当只显示一个字段时显示的格式

# 2.2 表中的记录默认显示的是对象,如果想定义显示多个字段,可以在admins.py文件中定义显示哪几个字段,如:#     class BookAdmin(admin.ModelAdmin):#         list_display = (‘title‘,‘publisher‘,‘publication_date‘)  #指定显示的字段##     admin.site.register(models.Author)#     admin.site.register(models.Book,BookAdmin)  # 注册的时候,把定义的BookAdmin类作为参数传入进来#     admin.site.register(models.Publisher)# 3.表中字段名称的显示默认是字段名,可以通过verbose_name="中文名" 显示成中文
时间: 2024-11-03 03:45:35

python2.0_day19_后台数据库设计思路的相关文章

第一篇:无角牛MVC通用后台数据库设计

v\:* {behavior:url(#default#VML);} o\:* {behavior:url(#default#VML);} w\:* {behavior:url(#default#VML);} .shape {behavior:url(#default#VML);} Normal 0 false 7.8 磅 0 2 false false false EN-US ZH-CN X-NONE /* Style Definitions */ table.MsoNormalTable {

公交车路线查询系统后台数据库设计--换乘算法改进与优化

在<查询算法>一文中已经实现了换乘算法,但是,使用存储过程InquiryT2查询从“东圃镇”到“车陂路口”的乘车路线时,发现居然用了5分钟才查找出结果,这样的效率显然不适合实际应用.因此,有必要对原有的换乘算法进行优化和改进.在本文中,将给出一种改进的换乘算法,相比原有的算法,改进后的算法功能更强,效率更优. 1. “压缩”RouteT0 假设RouteT0有以下几行 如下图所示,当查询S1到S4的二次换乘路线时,将会产生3×2×4=24个结果 从图中可以看出,第1段路线中的3条线路的起点和站

四:后台数据库设计(化妆品表格)

1.数据库字段的设计: 1.1.在数据库moon中新建表格"MakeUp" 1.2.具体的字段含义: brand: "", //商品的类型 careType:" ", //护理类型 //可选值:facialCare:面部护理类型 : perfumeCosmetics:香水彩妆类型 :img:[ ],//商品图片  useType:" " , //用途类型,可选值:"口红" :"化妆工具"

基于Extjs的web表单设计器 第五节——数据库设计

这里列出表单设计器系列的内容,6.7.8节的内容应该在春节后才有时间出了.因为这周末就请假回老家了,准备我的结婚大事.在此提前祝大家春节快乐! 基于Extjs的web表单设计器 基于Extjs的web表单设计器 第一节 基于Extjs的web表单设计器 第二节——表单控件设计 基于Extjs的web表单设计器 第三节——控件拖放 基于Extjs的web表单设计器 第四节——控件拖放 基于Extjs的web表单设计器 第五节——数据库设计 基于Extjs的web表单设计器 第六节——界面框架设计

网上外卖及订餐系统的数据库设计

背景:互联网越来越发达,宅男越来越宅,网上订餐送叫外卖的越来越多. 注:本文仅做后台数据库设计,不做系统功能设计. 一.数据库需求分析 1.用户分为游客.注册用户和管理员用户,只有登录用户才能进行网上订餐,游客仅能浏览餐厅及菜肴信息,只有管理员身份才能进行后台管理 2.一个餐厅设计一张菜单:一张订单对应一个送餐员,可以包含多个菜肴:一个客服管理员可以管理多张订单 3.每个菜肴从属于一个菜系,一个菜单,一个餐厅 4.一个用户可以选择多个菜肴,产生多个订单 5.一张菜单每次对应一个优惠活动 二.数据

python2.0_day19_充分使用Django_form实现前端操作后台数据库

在前面的<python2.0_day19_学员管理系统之前端用户交互系统>一节中,我们实现了前端展示customer客户纪录.在<python2.0_day19_前端分页功能的实现>一节中,我们实现了网页中最常用的分页功能.最终我们在访问客户咨询纪录表的前端页面的效果如图: 能实现这个效果,对于我们这种新手,算是小有成就了.那么接下来,我们想实现点击前面的ID号,1,2,3就能进入该条目的编辑页面.这也是在Django admin后台管理中常见到的.那么我们之前在<pytho

用MongoDB数据库来管理办公系统中文档型的表单和信息——通用流程化应用审批单设计思路(二,续)

1.办公系统中文档的定义 办公系统中的文档就是指对数据不敏感的业务,例如流程中的审批单.信息专栏.数据上报.信息记录等.而对于这些信息的管理,特别是时效性较强的管理记录,仍采用关系型数据库进行管理. (1)流程中审批单 流程中审批单由功能按钮区.特殊功能区.业务表单区.附件区.审批意见区等区域构成,其中,业务表单区理论上包含附件和意见,但是由于附件和意见的业务特殊性,需要单独进行管理,剩下的业务表单就可以看作文档了. 在一些流程审批业务中,业务信息有的是以Excel或word文件等方式专递,这样

数据库水平切分的原理探讨、设计思路--数据库分库,分表,集群,负载均衡器

本文转载:http://www.cnblogs.com/olartan/archive/2009/12/02/1615131.html 第1章  引言 数据量巨大时,首先把多表分算到不同的DB中,然后把数据根据关键列,分布到不同的数据库中.库分布以后,系统的查询,io等操作都可以有多个机器组成的群组共同完成了.本文主要就是针对,海量数据库,进行分库.分表.负载均衡原理,进行探讨,并提出解决方案. 随着互联网应用的广泛普及,海量数据的存储和访问成为了系统设计的瓶颈问题.对于一个大型的互联网应用,每

数据库架构设计思路

一 .58同城数据库架构设计思路 (1)可用性设计 解决思路:复制+冗余 副作用:复制+冗余一定会引发一致性问题 保证"读"高可用的方法:复制从库,冗余数据,如下图  带来的问题:主从不一致 解决方案:见下文 保证"写"高可用的一般方法:双主模式,即复制主库(很多公司用单master,此时无法保证写的可用性),冗余数据,如下图  带来的问题:双主同步key冲突,引不一致 解决方案: a)方案一:由数据库或者业务层保证key在两个主上不冲突 b)方案二:见下文 58同