vue+django restful framework 電商專案(二)---資料表的設計
這一節開始我們來開始做這個專案, 至於專案的新建還有檔案結構, 我就不做詳細介紹了,這些步驟在這個部落格都有:http://www.cnblogs.com/derek1184405959/p/8733578.html 我呢,從來就不喜歡照搬別人的做, 反而喜歡多問幾個為什麼, 為什麼要這麼做? 因為我在之前遇到學習上的一個問題, 就是我看著老師講的視訊來就很會, 但是一旦脫離老師的視訊, 要自己開發呢? 又不會了, 這是因為什麼? 歸根到底是因為我們沒有明白為什麼要那麼做, 為什麼要那麼設計, 做專案的過程中要把自己當做專案負責人去做, 這樣你才會學的更多, 上面提到的那個部落格, 已經做的很好, 很詳細了, 我主要是解釋為什麼這麼做. 那麼開始做吧.
三. models設計
3.1 專案初始化
(1)虛擬環境下安裝
解釋以下幾點:
1. 為什麼要使用虛擬環境? 因為django的版本各個版本有所不同, 而且django的外掛也比較挑剔, 對有些版本適合, 對有些版本不適合, 所以我們可以建一個虛擬環境, 在虛擬環境下安裝你想要的版本, 這樣就不會因為版本的差異而產生bug了.
2.解釋一下這幾個外掛是什麼作用的, djangorestframework和django是專案的精髓, 這就不用說了吧, 然後即使markdown, 對於程式設計師來說, 這都不陌生吧, 這是一款編輯器, 因為我們要寫api, api是要給自己或者別人用的, 那麼自然而然少不了生成api文件吧, 用這個外掛可以很方便的生產api說明.django-filter是django的依賴包, 一定要安裝的, 接著是pillow是圖片處理的外掛, pymysql是python先mysql的庫.
(2) 建立專案
按照部落格來
(3)MYsql的配置
在setting.py檔案改DATABASES為下面的內容, 其中資料庫名字, 賬號, 密碼, ip, 埠(一般不用改)這些資訊按照自己的資料庫資訊修改, 不要盲目照搬照抄.注意下面最後一句, 不要寫成'OPTIONS':{'init_command': 'SET storage_engine=INNODB'} 不然會報錯, 在圖下解釋原因
DATABASES = { 'default': { 'ENGINE': 'django.db.backends.mysql', 'NAME': 'mxshop', #資料庫名字 'USER': 'root', #賬號 'PASSWORD': '123456', #密碼 'HOST': '127.0.0.1', #IP 'PORT': '3306', #埠 #這裡引擎用innodb（預設myisam） #因為後面第三方登入時，要求引擎為INNODB # 'OPTIONS':{'init_command': 'SET storage_engine=INNODB'}, #這樣設定會報錯，改為 "OPTIONS":{"init_command":"SET default_storage_engine=INNODB;"} } }
原因是mysql版本間的不相容: 上面那條語句適用了低版本的mysql, 下面那條適用於新版的mysql, 至於什麼是新版本,什麼是高版本, 在這不好做定論, 可以先試上面那個語句, 要是執行出錯, 就用下面那條語句.
(4)專案目錄結構
這裡有個python import的小知識:
Python import module 的搜尋路徑由sys.path指定，實質為一個列表，列表索引先後決定搜尋優先順序。
模組要處於Python搜尋路徑中的目錄裡才能被匯入，但我們不喜歡維護一個永久性的大目錄，因為其他所有的Python指令碼和應用程式匯入模組的時候效能都會被拖累。本節程式碼動態地在該路徑中添加了一個"目錄"，當然前提是此目錄存在而且此前不在sys.path中。sys.path是個列表，所以在末尾新增目錄是很容易的，用sys.path.append就行了。當這個append執行完之後，新目錄即時起效，以後的每次import操作都可能會檢查這個目錄。如同解決方案所示，可以選擇用sys.path.insert(0,…，這樣新新增的目錄會優先於其他目錄被import檢查。即使sys.path中存在重複，或者一個不存在的目錄被不小心新增進來，也沒什麼大不了，Python的import語句非常聰明，它會自己應付這類問題。但是，如果每次import時都發生這種錯誤（比如，重複的不成功搜尋，作業系統提示的需要進一步處理的錯誤），我們會被迫付出一點小小的效能代價。為了避免這種無謂的開銷，本節程式碼在向sys.path新增內容時非常謹慎，絕不加入不存在的目錄或者重複的目錄。程式向sys.path新增的目錄只會在此程式的生命週期之內有效，其他所有的對sys.path的動態操作也是如此。
sys.path.insert(1, path)，定義搜尋路徑的優先順序，序號從0開始，表示最大優先順序，sys.path.insert()加入的是臨時搜尋路徑，程式退出後失效。使用sys.path.append()方法可以臨時新增搜尋路徑，方便更簡潔的import其他包和模組。這種方法匯入的路徑會在python程式退出後失效。加入上面那三條語句是為了更好的import和維護, 這是我的見解, 不知道是不是這樣.
3.2 user modules的設計
設計models的方法: 分析頁面結構, 看看需要幾個資料表, 在分析資料表的欄位, 其實我認為這就是我們的分類和從組的能力,
設計資料庫是一門很深的學問, 我也在慢慢在學習. 看我怎麼設計這些models的,
因為前段時間我還執行這vue前端專案的, 不過現在後臺伺服器掛了, 不能運行了, 如圖所示:
我想想辦法吧.
這樣吧, 伺服器掛了, 我這邊沒辦法解釋了, 只有按照部落格說的那樣來吧, models這一塊的設計沒辦法講解了, 我們就這樣先過去吧.
來看看部落格的使用者表吧, 先細說一點, 就是
UserProfile繼承了AbstractUser這個類, 而這個類有一些基本的欄位, 我們是為了省去定義那些必須的欄位, 所以才繼承這個的, AbstractUser這個django自帶的使用者表, 那麼我們新建了使用者表後, 系統怎麼認的出我們的表呢, 在setting.py下:
其他的欄位我就不多說了, 比較常見.
3.3 goods modules的設計
（3）商品分類model 設計
借用一下別人的圖:
可以看出, 這裡總共有三類, 那麼是不是我們要建三個表來表示呢? 可以建, 但這不是最好的方式, 試想一下, 如果我有n個類, 是不是要建n個表呢? 這樣就有點不好了吧,我們可以這樣, 我的類別表中有一個索引, 指向上一級類別的外來鍵, 是不是就可以無線延展了, 就像我們學c語言連結串列一樣, 這裡我們也採用這種方式來. 在models中產生一個外來鍵, 指向父類. 如下圖所示:
其他的我就不多說了, 按照這裡來寫就是了.
（4）商品model設計
這裡我就沒什麼說的, 直接按照教程寫就是了, 那些欄位也很容易看出來.
（4）首頁商品輪播圖model設計
因為首頁的商品輪播圖片是大圖，跟商品詳情裡面的圖片不一樣，所以要單獨寫一個首頁輪播圖model
（5）商品廣告和熱搜model
照著教程寫......
3.5.使用者操作的model設計
.........
四 資料庫遷移
(一) 這裡說一下資料庫的遷移操作:
1. tools->run manage.py task 開啟後出現一個錯誤
這個錯誤表示:django.core.exceptions.ImproperlyConfigured：應用程式標籤不是唯一的，重複的：使用者
因為我們新建工程的時候, 軟體已經自動幫你建立了user app, 而且也在setting.py中配置好了,所以我們要把
INSTALLED_APPS中的users去掉,
再次執行, 出現錯誤:
解決辦法: 點進去,
去掉末尾的那個逗號就可以了
然後繼續點 run manage.py task, 之後我們就可以做資料庫遷移了,
在命令列執行makemigrations 
注意這裡可以帶appname, 也可以不帶, 如果不帶則做全部app的資料庫遷移, 如果帶了, 則對相應的app資料庫遷移
執行此條命令有什麼用呢?
執行這條命令後, django就知道要對哪些app進行遷移(注意: 這裡還沒有遷移), 遷移的記錄在每個app下的migrations檔案下的000x_initial.py檔案下. 我們可以開啟相應的檔案
之後我們再執行migrate:
這樣django就會執行上一步那些要遷移的記錄, 做資料庫相應的遷移, 我們在資料庫就可以看到生產了好多相應的表
其中, django_migrations記錄了遷移的記錄
到此, 資料庫的遷移完成了,
接下來我講一下關於資料庫的幾點坑:
1. 資料庫表的操作理論上可以基於軟體操作, 也可以基於django的程式碼操作, 前外不要兩者結合, 因為這樣會出現出乎意料的bug
2. 如果要新增欄位, 只需在原來的基礎上修改, 修改重新執行 makemigrations 和migrate就行了.
3. 如果發現設計的表很亂, 可以去資料庫把相應的表刪除, 然後重新設計表結構, 重新生產表, 一定要刪除原來的表
這一章就講這麼多.