CoolBlog開發筆記第4課:數據庫模型設計

時間 2019-12-02

原文原文鏈接

教程目錄

前言

　　我新書《Python爬蟲開發與項目實戰》出版了。這本書包括基礎篇，中級篇和深刻篇三個部分，不只適合零基礎的朋友入門，也適合有必定基礎的爬蟲愛好者進階，若是你不會分佈式爬蟲，不會千萬級數據的去重，不會怎麼突破反爬蟲，不會分析js的加密，這本書會給你驚喜。若是你們對這本書感興趣的話，能夠看一下 試讀樣章。廢話少說，開始講正題。從上一節咱們知道home應用須要涉及文章，分類和標籤三個部分，其實這就是我的博客系統最核心的功能：發表文章。下面咱們分析一下數據庫該如何設計？sql

1.4.1數據庫設計

　　1.先從分類提及，從下圖中咱們知道一個博客中對文章有不少分類，所以分類須要做爲單獨的數據表，裏面須要存儲分類的id和名稱。數據庫

　　2.標籤和分類相似，以下所示，博客有不少標籤標記文章的主題，標籤須要做爲單獨的數據表，裏面須要存儲標籤的id和名稱。django

　　3.文章的存儲是相對複雜的，從項目分析的圖1.4能夠看到，文章數據表須要存儲文章的標題，內容，建立時間，修改時間，摘要，分類，標籤，做者，瀏覽量和評論數，要存儲的數據有幾個須要注意：分類，標籤和評論數。數據庫設計

　　首先在設計數據表時不考慮評論數，由於評論咱們已經做爲一個獨立的應用，並且這和評論數據表與文章數據表的關係有關聯，以後在講評論功能時會說明。分佈式

文章數據表中有分類和標籤的字段，若是你們有設計數據庫的經歷，此時應該很敏感，這時候須要考慮文章數據表與分類數據表，標籤數據表的關係。post

一個分類下能夠有不少文章，而一篇文章只能有一個分類，這是一對多的關係。
一個標籤下能夠有不少文章，一樣一篇文章能夠有不少標籤，這是多對多的關係。

經過上面的分析，咱們使用Mysql Workbench設計以下三個數據表:Category表，Tag表和Article表，並描述了三個表之間的關係。加密

　　Category表經過外鍵與Acticle表相連，而Tag表與Article之間很特殊。你們會發現很奇怪，爲何設計了三個表，但是上圖中卻多出了一個Article_has_Tag表。這是爲何呢？其實這在數據庫設計中很常見，描述兩個表多對多的關係時，會生成一箇中間表，將多對多的關係轉化爲兩個表和中間表一對多的關係，這樣可使用外鍵將表聯繫起來。不過在代碼實現時，是不用體現相似Acticle_has_Tag中間表的，Django會幫咱們完成，我們繼續往下看。

1.4.2編寫數據庫模型

打開home應用下的models.py文件，這個文件是專門用來描述應用的數據庫模型。

因爲經過ORM的方式，所以在models中一個類便是一個數據表，一個屬性對應着數據表中的字段。下面先把Category表列一下：

class Category(models.Model):
    #分類名稱
    name = models.CharField(max_length=50,verbose_name="分類名稱")

　　在上面的代碼中，定義一個數據庫模型，須要繼承models.Model類，name是類中的一個屬性，它是models.CharField的一個實例，對應着Category數據表中name字段。在1.4.1節中，設計的Category數據表中還有id字段，因爲Django會默認建立id字段做爲主鍵，這裏咱們不用再聲明。models.CharField類的的初始化參數max_length表明着這存儲數據的最大長度，verbose_name用來對name屬性進行描述，在界面顯示時有用。CharField主要用來存儲短文本，能夠看作是數據庫中的varchar(50)。一樣的道理，Tag類的內容以下：

class Tag(models.Model):
    # 名稱
    name = models.CharField(max_length=50,verbose_name="標籤名稱")

　　下面定義複雜的Acticle表，必定要看註釋。內容以下：

class Article(models.Model):
    # 文章標題
    title = models.CharField(max_length=70,verbose_name="文章標題")
    #文章內容
    body = models.TextField(verbose_name="文章內容",default='')
    #建立時間
    created_time = models.DateTimeField(verbose_name="建立時間")
    # 修改時間
    modified_time = models.DateTimeField(verbose_name="修改時間")
    # 摘要
    excerpt = models.CharField(max_length=200, blank=True,verbose_name="摘要")
    # 分類
    category = models.ForeignKey(Category,verbose_name="分類")
    # 標籤
    tags = models.ManyToManyField(Tag, blank=True,verbose_name=u"標籤")
    # 做者
    author = models.ForeignKey(User,verbose_name="做者")
    #瀏覽量
    views = models.PositiveIntegerField(defalut=0verbose_name="瀏覽量")

在上面的代碼中主要有幾點須要說明：

body使用TextField來描述，它和CharField不一樣，用來存儲大段的文本，default參數是用來設置字段的默認值，body默認設置爲空。
created_time和modified_time使用DateTimeField來表述，用來存儲日期，你們能夠想一想數據庫中用什麼類型存儲時間呢。
excerpt用來存儲文章的摘要，blank=True參數的意思是用來講明此字段能夠爲空值。
category用來表示分類，經過傳入Category類實例化ForeignKey，來描述一對多的關係。
tags表示文章標籤，經過傳入Tag類實例化ManyToManyField，來表述多對多的關係，同時傳入blank=True來設置能夠爲空。
author表示文章做者，你們會發現咱們使用了外鍵，這是由於User是Django內置的數據模型，從django.contrib.auth.models中導入的，專門用來負責用戶信息的處理，本質上User就是一個數據表。一個做者能夠擁有不少文章，而一篇文章只能有一個做者，是一對多的關係，所以使用外鍵和User數據模型創建聯繫。
Views表示瀏覽量，經過實例化models.PositiveIntegerField來實現，PositiveIntegerField該類型只容許正整數和0，也就是說Views>=0。

通過以上的分析，數據模型基本上創建起來了，不過這尚未結束，由於尚未完成模型到真實數據庫的遷移。接下來要作的是配置數據庫，完成代碼到數據庫的「翻譯」。

1.4.3數據庫模型遷移

　　打開CoolBlog工程CoolBlog目錄下的settings.py文件，其中Django已經默認配置好了sqlite3數據庫。

　　DATABASES變量用來配置數據庫，ENGINE表明使用數據庫引擎，NAME對於sqlite3這種單文件數據庫來講，表明着它的存儲路徑。可是此次咱們不用默認的sqlite3數據庫，在稍微大型的項目中，Mysql纔是標配。首先使用Navicat for MySQL打開MySQL，新建一個coolblog數據庫。

新建成功後，我們接着在settings.py文件中配置MySQL。修改以下：

DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.mysql',
        'NAME': 'coolblog',#數據庫名稱
        'USER':'root',#用戶名
        'PASSWORD':'',#密碼爲空
        'HOST':'127.0.0.1',#主機
        'PORT':'3308'#端口
    }
}

　　你們根據本身的MySQL進行配置。若是不想用MySQL，能夠依然保持原樣。配置完成後，開始進行經過Django提供的命令進行數據庫遷移。激活虛擬環境，並切換到CoolBlog項目下，首先運行 python manage.py makemigrations命令會報出以下的錯誤，大體的意思是缺乏MySQLdb模塊。

　　因爲咱們使用MySQL做爲數據庫遷移，須要安裝python版本MySQL引擎，Django默認使用MySQLdb。接下來理所固然是安裝MySQLdb，可是做爲有安裝經驗的人，很負責任地告訴你們MySQLdb在Windows平臺下安裝很不方便，尤爲是有多個Python版本的時候，坑不少，所以咱們這裏不使用MySQLdb，咱們使用另一個更加友好流行的引擎:PyMySQL。咱們在虛擬環境中運行:pip3 install pymysql。安裝成功後，咱們須要在與settings.py同級目錄的__init__文件中加入如下代碼：

import pymysql
pymysql.install_as_MySQLdb()

　　這樣就將Django默認的MySQLdb進行了替換。下面接着運行python manage.py makemigrations和python manage.py migrate命令。執行效果以下圖所示：

這樣就完成了數據庫模型的遷移，那我們看看數據庫有沒有新建的表？下圖所示，Django已經幫助咱們完成了數據庫的遷移，裏面是否是還有以前說的中間表!

下面給你們講解一下上面兩條數據模型遷移命令到底幹了些什麼事情？

makemigrations命令：是用來記錄應用數據模型的改動，這些改動會記錄到應用所在目錄的migrations文件夾下，你們會看到裏面產生了一些python文件,好比初次生成的0001_initial.py文件。
migrate命令纔是真正意義上將應用數據模型映射到數據庫中，Django經過檢測migrations文件夾下的文件，就能夠知道咱們對數據模型作了哪些修改，而後Django將這些改動翻譯成SQL語句，並做用於數據庫。好比home應用，migrate命令實際上是在檢查剛纔makemigrations命令生成的0001_initial.py腳本，將這些改動應用到數據庫中。

那Django將這些模型的改動翻譯成什麼樣的SQL語句呢？我麼能夠經過sqlmigrate 命令進行查看。在命令行中執行：python manage.py sqlmigrate home 0001。以下圖所示。

　　你們有沒有發現，除了home應用的數據庫模型進行了遷移，還有不少數據的改動，其實這是爲Django內置的應用進行數據模型的遷移。你們能夠和settings.py中的INSTALLED_APPS變量聯繫起來看。

　　本節課程結束了，下一節我們接着講，要涉及到請求與響應方面的內容了。