Pycharm開發(fā)Django項目創(chuàng)建ORM模型的問題

更新時間：2021年10月20日 10:47:07 作者：白日夢想家UUC

ORM，全稱Object Relational Mapping，通過ORM我們可以通過類的方式去操作數(shù)據(jù)庫，而不用再寫原生的SQL語句，下面通過本文給大家介紹Pycharm開發(fā)Django項目ORM模型介紹，感興趣的朋友一起看看吧

隨著項目越來越大，采用寫原生SQL的方式在代碼中會出現(xiàn)大量的SQL語句，那么問題就出現(xiàn)了：

SQL語句重復利用率不高，越復雜的SQL語句條件越多，代碼越長。會出現(xiàn)很多相近的SQL語句。
很多SQL語句是在業(yè)務邏輯中拼出來的，如果有數(shù)據(jù)庫需要更改，就要去修改這些邏輯，這會很容易漏掉對某些SQL語句的修改。
寫SQL時容易忽略web安全問題，給未來造成隱患。SQL注入。

ORM，全稱Object Relational Mapping，中文叫做對象關(guān)系映射，通過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)，支持多個關(guān)系數(shù)據(jù)庫引擎，包括流行的MySQL、PostgreSQL和SQLite。可以非常輕松的切換數(shù)據(jù)庫。

創(chuàng)建ORM模型：

ORM模型一般都是放在app的models.py文件中。每個app都可以擁有自己的模型。并且如果這個模型想要映射到數(shù)據(jù)庫中，那么這個app必須要放在settings.py的INSTALLED_APP中進行安裝。以下是寫一個簡單的書籍ORM模型。示例代碼如下：

from django.db import models
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ù)庫中，總結(jié)起來就是以下幾步：