聚合查询:
需要先导入一些模块:
from django.db.models import Max, Min, Sun, Cont, Avg """ 聚合函数需要使用的关键字是: aggregate Max: 筛选最大的数据 Min: 求最小值 Sun: 求同一类数据的总和 AVg: 求字段内数据的平均值 Cont: 统计数量 分组查询关键字: annotate """
F与Q查询:
也需要先导入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中的事务简介:
扫描二维码关注公众号，回复：
8009234 查看本文章
""" ACID """ """ 原子性: 原子性是指事务包含的所有操作要么全部成功，要么全部失败回滚，因此事务的操作如果成功就必须要完全应用到数据库，如果操作失败则不能对数据库有任何影响。 假如用户在一个事务内完成了对数据库的更新，这时所有的更新对外部世界必须是可见的，或者完全没有更新。前者称事务已提交，后者称事务撤消（或流产）。
DBMS必须确保由成功提交的事务完成的所有操纵在数据库内有完全的反映，而失败的事务对数据库完全没有影响 一致性: 一致性是指事务必须使数据库从一个一致性状态变换到另一个一致性状态，也就是说一个事务执行之前和执行之后都必须处于一致性状态。 一致性处理数据库中对所有语义约束的保护。假如数据库的状态满足所有的完整性约束，就说该数据库是一致的。例如，当数据库处于一致性状态S1时，
对数据库执行一个事务，在事务执行期间假定数据库的状态是不一致的，当事务执行结束时，数据库处在一致性状态S2 隔离性: 隔离性是当多个用户并发访问数据库时，比如操作同一张表时，数据库为每一个用户开启的事务，不能被其他事务的操作所干扰，多个并发事务之间要相互隔离。 DBMS可以在并发执行的事务间提供不同级别的分离。分离的级别和并发事务的吞吐量之间存在反比关系。较多事务的可分离性可能会带来较高的冲突和较多的事务流产。
流产的事务要消耗资源，这些资源必须要重新被访问。因此，确保高分离级别的DBMS需要更多的开销。
持久性: 指的是只要事务成功结束，它对数据库所做的更新就必须永久保存下来。即使发生系统崩溃，重新启动数据库系统后，数据库还能恢复到事务成功结束时的状态。 持久性意味着当系统或介质发生故障时，确保已提交事务的更新不能丢失。即对已提交事务的更新能恢复。一旦一个事务被提交，DBMS必须保证提供适当的冗余，
使其耐得住系统的故障。所以，持久性主要在于DBMS的恢复性能。 """
数据库的三大范试:
""" 1、第一范式（1NF）： 所谓第一范式（1NF）是指在关系模型中，对于添加的一个规范要求，所有的域都应该是原子性的，即数据库表的每一列都是不可分割的原子数据项，而不能是集合，数组，记录等非原子数据项。
即实体中的某个属性有多个值时，必须拆分为不同的属性。在符合第一范式（1NF）表中的每个域值只能是实体的一个属性或一个属性的一部分。简而言之，第一范式就是无重复的域。 说明：在任何一个关系数据库中，第一范式（1NF）是对关系模式的设计基本要求，一般设计中都必须满足第一范式（1NF）。不过有些关系模型中突破了1NF的限制，这种称为非1NF的关系模型。
换句话说，是否必须满足1NF的最低要求，主要依赖于所使用的关系模型。
2、第二范式（2NF） 在1NF的基础上，非码属性必须完全依赖于候选码（在1NF基础上消除非主属性对主码的部分函数依赖） 第二范式（2NF）是在第一范式（1NF）的基础上建立起来的，即满足第二范式（2NF）必须先满足第一范式（1NF）。第二范式（2NF）要求数据库表中的每个实例或记录必须可以被唯一地区分。
选取一个能区分每个实体的属性或属性组，作为实体的唯一标识。例如在员工表中的身份证号码即可实现每个一员工的区分，该身份证号码即为候选键，任何一个候选键都可以被选作主键。在找不到候选键时，
可额外增加属性以实现区分，如果在员工关系中，没有对其身份证号进行存储，而姓名可能会在数据库运行的某个时间重复，无法区分出实体时，设计辟如ID等不重复的编号以实现区分，被添加的编号或ID选作主键。
（该主键的添加是在ER设计时添加，不是建库时随意添加） 第二范式（2NF）要求实体的属性完全依赖于主关键字。所谓完全依赖是指不能存在仅依赖主关键字一部分的属性，如果存在，那么这个属性和主关键字的这一部分应该分离出来形成一个新的实体，
新实体与原实体之间是一对多的关系。为实现区分通常需要为表加上一个列，以存储各个实例的唯一标识。简而言之，第二范式就是在第一范式的基础上属性完全依赖于主键。
3、第三范式（3NF） 在2NF基础上，任何非主属性不依赖于其它非主属性（在2NF基础上消除传递依赖） 第三范式（3NF）是第二范式（2NF）的一个子集，即满足第三范式（3NF）必须满足第二范式（2NF）。简而言之，第三范式（3NF）要求一个关系中不包含已在其它关系已包含的非主关键字信息。
例如，存在一个部门信息表，其中每个部门有部门编号（dept_id）、部门名称、部门简介等信息。那么在员工信息表中列出部门编号后就不能再将部门名称、部门简介等与部门有关的信息再加入员工信息表中。
如果不存在部门信息表，则根据第三范式（3NF）也应该构建它，否则就会有大量的数据冗余。简而言之，第三范式就是属性不依赖于其它非主属性，也就是在满足2NF的基础上，任何非主属性不得传递依赖于主属性。 """