作者：Vamei 出處：http://www.cnblogs.com/vamei 嚴禁轉載。
使用Python的Django模型的話，一般都會用它自帶的ORM（Object-relational mapping）模型。這個ORM模型的設計比較簡單，學起來不會特别花時間。不過，Django的ORM模型有自己的一套文法，有時候會覺得别扭。這裡聊一下我自己的體會。
這一部分算處理得比較好的部分。Django的資料模型的建立過程很簡單，就是繼承django.db.models中的Model類，然後給它增加屬性。每一個屬性可以對應關系資料庫中的一個字段。比如在一個叫myapp的Django App下，建立models.py檔案：
通過manage.py的makemigrations和migrate指令，就可以執行資料庫的遷移。上面的name屬性，就對應了生成的myapp_person表中名為"name"的一列。這裡的max_length=10對應了限制條件：
（在MySQL V4中，代表了10個位元組；在MySQL V5中，代表了10個字元。）
除了上面的字元類型，其他常見的字段類型，在Django都有對應的*Field來表達，比如TextField、DateField、DateTimeField、IntegerField、DecimalField。此外，還有一些常見的限制條件，除了上面的max_length，還有default、unique、null、primary_key等等。數字類型的限制條件有max、min、max_digits、decimal_places。這些限制條件都通過參數的形式傳給屬性。有一些限制條件是Django提供的，并沒有資料庫層面的對應物，比如blank。
(當blank參數為真時，對應字段可以為留為空白。)
在基本的模型設計上，Django ORM沒有留什麼坑。
Django中的一對一、多對一、多對多關系可以通過下面方式表達：
Customer的定義中，用到一對一、多對一、多對多關系。它們分别通過OneToOneField、ForeignKey和ManyToManyField來實作。
需要注意的是，在Django ORM中，隻能通過ForeignKey來定義多對一關系，不能顯示地定義一對多關系。但你可以使用模型對象的*_set文法來反向調用多對一關系。比如說：
就可以根據一對多關系，調到該公司下的所有客戶。此外，多對多關系也可以用類似的方式反向調用，比如：
此外，你還可以在模型中加入related_name參數，進而在檢討調用時，改用"*_set"之外的其他名稱，比如：
如果兩個模型之間有多個關系時，related_name可以防止*_set重名。
總的來說，上面的解決方案可以實作功能，并不影響使用。但我總是覺得這個解決方案有些醜陋。由于不能顯式地表達兩個模型之間的關系，模型之間的關系看起來不夠明了。特别是讀代碼時，第一個類定義完全沒法提示一對多的關系。我必須要看到了第二個類定義，才能搞明白兩個模型之間的關系。真希望有一種顯式說明關系的辦法，降低讀代碼時的認知負擔。
Django ORM可以通過一些方法來實作。其中的很多方法傳回的是Django自定義的QuerySet類的疊代器。Python看到疊代器時會懶惰求值，是以這些方法傳回時并不會真正進行資料庫操作。這樣，多個方法串聯操作時，就避免了重複操作資料庫。傳回QuerySet的常見方法包括：
對于依賴具體資料的操作，QuerySet會求值。比如周遊QuerySet時，就會先執行資料庫操作。用len()獲得QuerySet長度時，也會造成QuerySet估值。此外QuerySet一些方法，比get()、count()、earlist()、exists()等，都會對QuerySet進行求值。是以，在寫程式時，要注意QuerySet求值的時間點，避免重複的資料庫操作。
SQL的WHERE條件可以通過參數的形式來傳給方法。這些參數一般是"[字段]__[運算符]"的命名方式，比如：
除了contains，還有in、gt、lt、startswith、date、range等等操作符，能實作的WHERE條件确實夠全的了。
不過，這又是一個有點别扭的地方，即通過命名方式來控制查詢行為。我看過有的ORM是用lambda的形式來表達WHERE條件，還有的會做一個類似于contains()的方法，都要比Django ORM的方式好看。如果是跨表查詢，Django的方式就更醜了：
無限的雙下劃線啊……
Django實作聚合的方式簡直是噩夢。貌似ORM對表達GROUP BY很無力，源代碼裡的注釋就認輸了：
聚合的aggregate()和annotate()方法可以實作基本的功能，但稍微複雜一點，代碼就變得魔幻了：
看到一大串values()、annotate()變來變去，有沒有覺得頭暈？我覺得這種情況下，可以直接上原始的SQL查詢語句了，沒必要再自己折騰自己。
F表達式指代了一列，對于update操作時引用列的值有用。Q表達式代表了WHERE的一個條件，可以用于多個WHERE條件的連接配接。這些都是Django ORM用來彌補缺陷的。就拿Q表達式來說。查詢方法中跟多個參數的話，相當于多個WHERE條件。這些條件會預設為AND關系。為了表達OR和NOT關系，Django ORM就造了個Q表達式，比如：
為了彌補缺陷，Django ORM又增加了一種文法風格。于是，學習路上又多了一個坑……
總的來說，Django ORM在實作基礎的資料庫操作方面沒問題。但如果需要建構複雜的SQL語句，與其在Django ORM裡繞來繞去，還不如直接用原始的SQL語句。這個是我最強烈的一個感受。當然，Django ORM還是可用的工具。我寫這篇文章的目的，是提醒大家不要誤把糟糕的設計當做精巧的文法。
如果你喜歡這篇文章，歡迎推薦。