聚合查詢: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的基礎上,任何非主屬性不得傳遞依賴於主屬性。 """