聚合查询:git
须要先导入一些模块:数据库
from django.db.models import Max, Min, Sun, Cont, Avg """ 聚合函数须要使用的关键字是: aggregate Max: 筛选最大的数据 Min: 求最小值 Sun: 求同一类数据的总和 AVg: 求字段内数据的平均值 Cont: 统计数量 分组查询关键字: annotate """
F与Q查询:django
也须要先导入F与Q模块数组
from django.db.models import F, Q """ F() 的实例能够在查询中引用字段,来比较同一个 model 实例中两个不一样字段的值; F能够帮咱们取到表中某个字段对应的值来看成个人筛选条件,而不是我认为自定义常量的条件了,实现了动态比较的效果. Q查询默认是and 能够改写成or 咱们能够组合& 和| 操做符以及使用括号进行分组来编写任意复杂的Q 对象。 同时,Q 对象可使用~ 操做符取反,这容许组合正常的查询和取反(NOT) 查询。 查询函数能够混合使用Q 对象和关键字参数。全部提供给查询函数的参数(关键字参数或Q 对象)都将"AND”在一块儿。可是,
若是出现Q 对象,它必须位于全部关键字参数的前面。 """
orm字段及参数:并发
""" AutoField(Field) - int自增列,必须填入参数 primary_key=True BigAutoField(AutoField) - bigint自增列,必须填入参数 primary_key=True 注:当model中若是没有自增列,则自动会建立一个列名为id的列 from django.db import models class UserInfo(models.Model): # 自动建立一个列名为id的且为自增的整数列 username = models.CharField(max_length=32) class Group(models.Model): # 自定义自增列 nid = models.AutoField(primary_key=True) name = models.CharField(max_length=32) SmallIntegerField(IntegerField): - 小整数 -32768 ~ 32767 PositiveSmallIntegerField(PositiveIntegerRelDbTypeMixin, IntegerField) - 正小整数 0 ~ 32767 IntegerField(Field) - 整数列(有符号的) -2147483648 ~ 2147483647 PositiveIntegerField(PositiveIntegerRelDbTypeMixin, IntegerField) - 正整数 0 ~ 2147483647 BigIntegerField(IntegerField): - 长整型(有符号的) -9223372036854775808 ~ 9223372036854775807 BooleanField(Field) - 布尔值类型 NullBooleanField(Field): - 能够为空的布尔值 CharField(Field) - 字符类型 - 必须提供max_length参数, max_length表示字符长度 TextField(Field) - 文本类型 EmailField(CharField): - 字符串类型,Django Admin以及ModelForm中提供验证机制 IPAddressField(Field) - 字符串类型,Django Admin以及ModelForm中提供验证 IPV4 机制 GenericIPAddressField(Field) - 字符串类型,Django Admin以及ModelForm中提供验证 Ipv4和Ipv6 - 参数: protocol,用于指定Ipv4或Ipv6, 'both',"ipv4","ipv6" unpack_ipv4, 若是指定为True,则输入::ffff:192.0.2.1时候,可解析为192.0.2.1,开启此功能,须要protocol="both" URLField(CharField) - 字符串类型,Django Admin以及ModelForm中提供验证 URL SlugField(CharField) - 字符串类型,Django Admin以及ModelForm中提供验证支持 字母、数字、下划线、链接符(减号) CommaSeparatedIntegerField(CharField) - 字符串类型,格式必须为逗号分割的数字 UUIDField(Field) - 字符串类型,Django Admin以及ModelForm中提供对UUID格式的验证 FilePathField(Field) - 字符串,Django Admin以及ModelForm中提供读取文件夹下文件的功能 - 参数: path, 文件夹路径 match=None, 正则匹配 recursive=False, 递归下面的文件夹 allow_files=True, 容许文件 allow_folders=False, 容许文件夹 FileField(Field) - 字符串,路径保存在数据库,文件上传到指定目录 - 参数: upload_to = "" 上传文件的保存路径 storage = None 存储组件,默认django.core.files.storage.FileSystemStorage ImageField(FileField) - 字符串,路径保存在数据库,文件上传到指定目录 - 参数: upload_to = "" 上传文件的保存路径 storage = None 存储组件,默认django.core.files.storage.FileSystemStorage width_field=None, 上传图片的高度保存的数据库字段名(字符串) height_field=None 上传图片的宽度保存的数据库字段名(字符串) DateTimeField(DateField) - 日期+时间格式 YYYY-MM-DD HH:MM[:ss[.uuuuuu]][TZ] DateField(DateTimeCheckMixin, Field) - 日期格式 YYYY-MM-DD TimeField(DateTimeCheckMixin, Field) - 时间格式 HH:MM[:ss[.uuuuuu]] DurationField(Field) - 长整数,时间间隔,数据库中按照bigint存储,ORM中获取的值为datetime.timedelta类型 FloatField(Field) - 浮点型 DecimalField(Field) - 10进制小数 - 参数: max_digits,小数总长度 decimal_places,小数位长度 BinaryField(Field) - 二进制类型 """
自定义char字段:函数
# 如何自定义字段类型 class MyCharField(models.Field): def __init__(self,max_length,*args,**kwargs): self.max_length = max_length # 从新调用父类的方法 super().__init__(max_length=max_length,*args,**kwargs) def db_type(self, connection): return 'char(%s)'%self.max_length
orm中的事务简介: 性能
""" ACID """ """ 原子性: 原子性是指事务包含的全部操做要么所有成功,要么所有失败回滚,所以事务的操做若是成功就必需要彻底应用到数据库,若是操做失败则不能对数据库有任何影响。 假如用户在一个事务内完成了对数据库的更新,这时全部的更新对外部世界必须是可见的,或者彻底没有更新。前者称事务已提交,后者称事务撤消(或流产)。
DBMS必须确保由成功提交的事务完成的全部操纵在数据库内有彻底的反映,而失败的事务对数据库彻底没有影响 一致性: 一致性是指事务必须使数据库从一个一致性状态变换到另外一个一致性状态,也就是说一个事务执行以前和执行以后都必须处于一致性状态。 一致性处理数据库中对全部语义约束的保护。假如数据库的状态知足全部的完整性约束,就说该数据库是一致的。例如,当数据库处于一致性状态S1时,
对数据库执行一个事务,在事务执行期间假定数据库的状态是不一致的,当事务执行结束时,数据库处在一致性状态S2 隔离性: 隔离性是当多个用户并发访问数据库时,好比操做同一张表时,数据库为每个用户开启的事务,不能被其余事务的操做所干扰,多个并发事务之间要相互隔离。 DBMS能够在并发执行的事务间提供不一样级别的分离。分离的级别和并发事务的吞吐量之间存在反比关系。较多事务的可分离性可能会带来较高的冲突和较多的事务流产。
流产的事务要消耗资源,这些资源必需要从新被访问。所以,确保高分离级别的DBMS须要更多的开销。
持久性: 指的是只要事务成功结束,它对数据库所作的更新就必须永久保存下来。即便发生系统崩溃,从新启动数据库系统后,数据库还能恢复到事务成功结束时的状态。 持久性意味着当系统或介质发生故障时,确保已提交事务的更新不能丢失。即对已提交事务的更新能恢复。一旦一个事务被提交,DBMS必须保证提供适当的冗余,
使其耐得住系统的故障。因此,持久性主要在于DBMS的恢复性能。 """
数据库的三大范试: spa
""" 一、第一范式(1NF): 所谓第一范式(1NF)是指在关系模型中,对于添加的一个规范要求,全部的域都应该是原子性的,即数据库表的每一列都是不可分割的原子数据项,而不能是集合,数组,记录等非原子数据项。
即实体中的某个属性有多个值时,必须拆分为不一样的属性。在符合第一范式(1NF)表中的每一个域值只能是实体的一个属性或一个属性的一部分。简而言之,第一范式就是无重复的域。 说明:在任何一个关系数据库中,第一范式(1NF)是对关系模式的设计基本要求,通常设计中都必须知足第一范式(1NF)。不过有些关系模型中突破了1NF的限制,这种称为非1NF的关系模型。
换句话说,是否必须知足1NF的最低要求,主要依赖于所使用的关系模型。
二、第二范式(2NF) 在1NF的基础上,非码属性必须彻底依赖于候选码(在1NF基础上消除非主属性对主码的部分函数依赖) 第二范式(2NF)是在第一范式(1NF)的基础上创建起来的,即知足第二范式(2NF)必须先知足第一范式(1NF)。第二范式(2NF)要求数据库表中的每一个实例或记录必须能够被惟一地区分。
选取一个能区分每一个实体的属性或属性组,做为实体的惟一标识。例如在员工表中的身份证号码便可实现每一个一员工的区分,该身份证号码即为候选键,任何一个候选键均可以被选做主键。在找不到候选键时,
可额外增长属性以实现区分,若是在员工关系中,没有对其身份证号进行存储,而姓名可能会在数据库运行的某个时间重复,没法区分出实体时,设计辟如ID等不重复的编号以实现区分,被添加的编号或ID选做主键。
(该主键的添加是在ER设计时添加,不是建库时随意添加) 第二范式(2NF)要求实体的属性彻底依赖于主关键字。所谓彻底依赖是指不能存在仅依赖主关键字一部分的属性,若是存在,那么这个属性和主关键字的这一部分应该分离出来造成一个新的实体,
新实体与原实体之间是一对多的关系。为实现区分一般须要为表加上一个列,以存储各个实例的惟一标识。简而言之,第二范式就是在第一范式的基础上属性彻底依赖于主键。
三、第三范式(3NF) 在2NF基础上,任何非主属性不依赖于其它非主属性(在2NF基础上消除传递依赖) 第三范式(3NF)是第二范式(2NF)的一个子集,即知足第三范式(3NF)必须知足第二范式(2NF)。简而言之,第三范式(3NF)要求一个关系中不包含已在其它关系已包含的非主关键字信息。
例如,存在一个部门信息表,其中每一个部门有部门编号(dept_id)、部门名称、部门简介等信息。那么在员工信息表中列出部门编号后就不能再将部门名称、部门简介等与部门有关的信息再加入员工信息表中。
若是不存在部门信息表,则根据第三范式(3NF)也应该构建它,不然就会有大量的数据冗余。简而言之,第三范式就是属性不依赖于其它非主属性,也就是在知足2NF的基础上,任何非主属性不得传递依赖于主属性。 """