ORM模型介紹
隨著項目越來越大，采用寫原生SQL的方式在代碼中會出現(xiàn)大量的SQL語句，那么問題就出現(xiàn)了：
- SQL語句重復利用率不高，越復雜的SQL語句條件越多，代碼越長。會出現(xiàn)很多相近的SQL語句。
- 很多SQL語句是在業(yè)務邏輯中拼出來的，如果有數(shù)據(jù)庫需要更改，就要去修改這些邏輯，這會很容易漏掉對某些SQL語句的修改。
- 寫SQL時容易忽略web安全問題，給未來造成隱患。SQL注入。
ORM ，全稱 Object Relational Mapping ，中文叫做對象關系映射，通過 ORM 我們可以通過類的方式去操作數(shù)據(jù)庫，而不用再寫原生的SQL語句。通過把表映射成類，把行作實例，把字段作為屬性， ORM 在執(zhí)行對象操作的時候最終還是會把對應的操作轉(zhuǎn)換為數(shù)據(jù)庫原生語句。使用 ORM 有許多優(yōu)點：
- 易用性：使用 ORM 做數(shù)據(jù)庫的開發(fā)可以有效的減少重復SQL語句的概率，寫出來的模型也更加直觀、清晰。
- 性能損耗小： ORM 轉(zhuǎn)換成底層數(shù)據(jù)庫操作指令確實會有一些開銷。但從實際的情況來看，這種性能損耗很少（不足5%），只要不是對性能有嚴苛的要求，綜合考慮開發(fā)效率、代碼的閱讀性，帶來的好處要遠遠大于性能損耗，而且項目越大作用越明顯。
- 設計靈活：可以輕松的寫出復雜的查詢。
- 可移植性： Django 封裝了底層的數(shù)據(jù)庫實現(xiàn)，支持多個關系數(shù)據(jù)庫引擎，包括流行的 MySQL 、 PostgreSQL 和 SQLite 。可以非常輕松的切換數(shù)據(jù)庫。
創(chuàng)建ORM模型：
ORM 模型一般都是放在 app 的 models.py 文件中。每個 app 都可以擁有自己的模型。并且如果這個模型想要映射到數(shù)據(jù)庫中，那么這個 app 必須要放在 settings.py 的 INSTALLED_APP 中進行安裝。以下是寫一個簡單的書籍 ORM 模型。示例代碼如下：
|
1
2
3
4
5
6
|
class Book(models.Model): name = models.CharField(max_length=20,null=False) author = models.CharField(max_length=20,null=False) pub_time = models.DateTimeField(default=datetime.now) price = models.FloatField(default=0) |
以上便定義了一個模型。這個模型繼承自 django.db.models.Model ，如果這個模型想要映射到數(shù)據(jù)庫中，就必須繼承自這個類。這個模型以后映射到數(shù)據(jù)庫中，表名是模型名稱的小寫形式，為 book 。在這個表中，有四個字段，一個為 name ，這個字段是保存的是書的名稱，是 varchar 類型，最長不能超過20個字符，并且不能為空。第二個字段是作者名字類型，同樣也是 varchar 類型，長度不能超過20個。第三個是出版時間，數(shù)據(jù)類型是 datetime 類型，默認是保存這本書籍的時間。第五個是這本書的價格，是浮點類型。
還有一個字段我們沒有寫，就是主鍵 id ，在 django 中，如果一個模型沒有定義主鍵，那么將會自動生成一個自動增長的 int 類型的主鍵，并且這個主鍵的名字就叫做 id 。
映射模型到數(shù)據(jù)庫中：
將 ORM 模型映射到數(shù)據(jù)庫中，總結起來就是以下幾步：
- 在 settings.py 中，配置好 DATABASES ，做好數(shù)據(jù)庫相關的配置。
- 在 app 中的 models.py 中定義好模型，這個模型必須繼承自 django.db.models 。
- 將這個 app 添加到 settings.py 的 INSTALLED_APP 中。
- 在命令行終端，進入到項目所在的路徑，然后執(zhí)行命令 python manage.py makemigrations 來生成遷移腳本文件。
- 同樣在命令行中，執(zhí)行命令 python manage.py migrate 來將遷移腳本文件映射到數(shù)據(jù)庫中。
以上就是本文的全部內(nèi)容，希望對大家的學習有所幫助，也希望大家多多支持服務器之家。
原文鏈接：https://www.jianshu.com/p/38a2f24e8f4f
