django查看有多少數據表

可以使用邏輯關系運算符

例如：

SELECT*FROMtable_name

WHERE(條件1and條件2)查詢兩個條件都符合的結果，

或者

SELECT*FROMtable_name

WHERE(條件1or條件2)查詢符合兩個條件中滿足任一條件的結果。

Model是django項目的基礎,如果一開始沒有好好設計好,那麼在接下來的開發過程中就會遇到更多的問題.然而,大多數的開發人員都容易在缺少思考的情況下隨意的增加或修改model.這樣做的後果就是,在接下來的開發過程中,我們不得不做出更多努力來修正這些錯誤.

因此,在修改model時,一定盡可能的經過充分的考慮再行動!以下列出的是我們經常用到的一些工具和技巧:

South,用於數據遷移,我們會在每個django項目中都用到.但到django1.7時,將會有django.db.migrations代替.

django-model-utils,用於處理常見的模式,例如TimeStampedModel.

django-extensions,主要用到shell_plus命令,該命令會在shell中自動載入所有的app的model

1.基本原則

第一,將model分布於不同的app中.如果你的django項目中,有一個app擁有超過20個model,那麼,你就應當考慮分拆該app了.我們推薦每個app擁有不超過5個model.

第二,盡量使用ORM.我們需要的大多數資料庫索引都能通過Object-Relational-Model實現,且ORM帶給我們許多快捷方式,例如生成SQL語句,讀取/更新資料庫時的安全驗證.因此,如果能使用簡單的ORM語句完成的,應當盡量使用ORM.只有當純SQL語句極大地簡化了ORM語句時,才使用純SQL語句.並且,在寫純SQL語句是,應當優先考慮使用raw(),再是extra().

第三,必要時添加index.添加db_index=True到model中非常簡單,但難的是理解何時應該添加.在建立model時,我們事先不會添加index,只有當以下情況時,才會考慮添加index:

在所有的資料庫查詢中使用率在10%-25%時

或當有真實的數據,或能正確估計出使用index後的效果確實滿意時

第四,注意model的繼承.model的繼承在django中需要十分小心,django提供了三種繼承方式,1.abstractbaseclass繼承(不要和Pyhton標准庫的abc模塊搞混),2.多表(multi-table)繼承,3.proxymodel繼承.下表羅列了這三種繼承的優劣:

django的創造者和其他許多開發人員都認為,多表繼承的方法不是一個良好的方法.因此我們強烈建議大家不要使用該方法.下面列舉了一些常見的如何選擇model繼承的情形:

如果只有少數model擁有重復的field時,大可不必使用model繼承,只需要在每個model中添加這些相同的field即可.

如果有足夠的model擁有重復的field時,大多是情況下,可以使用abstractbaseclass繼承,將相同的field提取到abstractbaseclass中.

Proxymodel繼承很少被用到,和其他兩種繼承也有著許多不一樣之處.

請不要使用多表(multi-table)繼承,因為它既消耗資源又復雜,如果可以,盡量使用OneToOneFields和ForeignKeys代替.

django項目中,創建時間和修改時間這兩個field是最用到的,下面給出一個abstractbaseclass繼承的例子:

2.DjangoModel的設計

如何設計出好的djangomodel可能是最難也是最復雜的一個話題了,在此,我們看看一些基本的技巧吧:

a.規范化

我們首先建議了解資料庫規范化(databasenormalization).如果你還不清楚這是什麼,那麼,我們強烈建議你先閱讀一下相關的書籍,或搜索"關系型資料庫設計"或"資料庫規范化".在創建djangomodel之前,應當首先保證設計的資料庫是規范化的.

b.cache

正確的使用cache能幫助我們提高資料庫的性能.詳細的信息,我們會在今後的文章中作進一步介紹.

c.何時使用null和blank

當定義modelfield時,我們可以設置null=True和blank=True(默認都是False),知道何時設置null和blank對於開發人員也是十分重要的,在下面的表格中,我們一一列舉了如何使用這兩個選項:

d.什麼時候使用BinaryField

在django1.6中,新增了BinaryField,用於儲存二進制數據(binarydata或bytes).對於BinaryField,我們無法使用ORM的filters,excludes或其他SQL操作.但在少數情況下,我們會用到BinaryField,例如MessagePack格式的內容,感測器接受的原始數據和壓縮數據等.但需要注意的是,BinaryData一般都十分龐大,因此可能會拖慢資料庫的速度.如果發生這一現象,我們可以將binarydata儲存在文件中,然後使用FileField儲存該文件的路徑信息.

還有,不要從BinaryField中直接讀取文件並呈獻給用戶.因為,1.從資料庫讀寫總是比從文件系統讀寫慢;2.資料庫備份會變得十分龐大,花費更多的時間;3.獲得文件的過程,增加了從django到資料庫的這一環節.

3.不要替換默認的ModelManager

從ORM獲取model,實際上是通過django中的Modelmanager完成的,django為每一個model提供了默認的modelmanager,我們不建議將其替換掉,因為:

當使用model繼承時,model會繼承abstractbaseclassmodel的modelmanager,而不會繼承非abstractbaseclass的manager.

model的第一個modelmanager通常作為默認的manager,當被替換時,可能會發生不可預測的問題.

4.資料庫事務(Transaction)

在django1.6中,ORM默認會autocommit每一個資料庫查詢,也就是說,每次使用m.create()或m.update()時,在資料庫中馬上就會做出相應的修改.這樣做的好處就是簡化了初學者對ORM的理解.但壞處就是,當一個view中包含兩個資料庫修改,可能一個成功,但另一個失敗,這就可能導致資料庫不完整,給我們帶來很大的危險.

解決這一問題的方法就是使用資料庫transaction,即將一系列資料庫操作包含在一個transaction中,當其中有一個失敗時,其他操作也會自動回退.Django1.6為我們帶來了一套嶄新的既簡單又強大的transaction機制,使我們方便的使用資料庫transaction.

a.將整個httprequest包裹在transaction中

django給我們提供了一個簡單地方法,將一個httprequest中的所有資料庫操作包裹在transaction中:

只需要在資料庫設置中加入'ATOMIC_REQUESTS':True選項,就能將整個httprequest包裹在transaction中.這樣做的好處顯而易見是是安全,但壞處則是性能可能會下降,因此隨著流量的增大,我們必須採取更針對性的transaction.其次,需要注意的是,回退的只是資料庫的狀態,而不包括其他費資料庫項,例如發送email等.所以當涉及這些非資料庫項時,我們應當使用transaction.con_atomic_request()修飾(decorate)這些view:

b.更明確地transaction控制

更明確地transaction控制意味著提高真題webapp的性能,但也意味著更多的開發時間.大多數網站下,由於有限的流量,使用ATOMIC_REQUESTS已經足夠.在使用手動transaction控制時,應當注意:

不做數據修改的操作,應當排除在transaction之外

做數據修改的操作,則應在transaction內

特殊情況下,可以違反以上兩條

需要注意的是,當view返回的是django.http.StreamingHttpResponse時,應當設置ATOMIC_REQUESTS為false,或使用transaction.non_atomic_requests將該view修飾.因為對於view本身,是可以使用transaction的,但對於之後生成的responsestream觸發的額外SQL查詢,會自動變為django默認的autocommit模式.

Students="你定義的Models"

Students.objects.filter(name='張三').filter(num=飓')

1、新建一個JUPYTERNOTEBOOK文檔。

2、定義一個LIST列表並且列印看看結果。list=[3,9,-7]print(list)。

3、為列表增加一個數字。list.append(10)print(list)。

4、字元串也是可以增加進去的。list.append("string123")print(list)。

5、列表裡面更是可以含有其它列表。list.append([-3,-4])print(list)。

6、如果要刪除最後一個列表的值，可以這樣處理。list.pop()print(list)。