python-django電商項目-需求分析架構設計數據庫設計_20191115

python-django電商項目需求分析

1.用戶模塊

1）註冊頁

• 註冊時校驗用戶名是否已被註冊。
• 完成用戶信息的註冊。
• 給用戶的註冊郵箱發送郵件，用戶點擊郵件中的激活連接完成用戶帳戶的激活。

2）登陸頁

• 實現用戶的登陸功能。

3）用戶中心

• 用戶中心信息頁：顯示登陸用戶的信息，包括用戶名、電話和地址，同時頁面下方顯示出用戶最近瀏覽的商品信息。
• 用戶中心地址頁：顯示登陸用戶的默認收件地址，頁面下方的表單能夠新增用戶的收貨地址。
• 用戶中心訂單頁：顯示登陸用戶的訂單信息。

4）其餘

• 若是用戶已經登陸，頁面頂部顯示登陸用戶的信息。

因此這個模塊有5個頁面

• 註冊頁
• 登陸頁
• 用戶中心-信息頁
• 用戶中心-地址頁
• 用戶中心-訂單頁

2.商品相關

1）首頁

• 動態指定首頁輪播商品信息。
• 動態指定首頁活動信息。
• 動態獲取商品的種類信息並顯示。
• 動態指定首頁顯示的每一個種類的商品(包括圖片商品和文字商品)。
• 點擊某一個商品時跳轉到商品的詳情頁面。

2）商品詳情頁

• 顯示出某個商品的詳情信息。
• 頁面的左下方顯示出該種類商品的2個新品信息。

3）商品列表頁

• 顯示出某一個種類商品的列表數據，分頁顯示並支持按照默認、價格、和人氣進行排序。
• 頁面的左下方顯示出該種類商品的2個新品信息。

4）其餘

• 經過頁面搜索框搜索商品信息。

因此這個模塊有四個頁面：

• 首頁
• 商品詳情頁
• 商品列表頁
• 搜索結果頁

3.購物車相關

• 列表頁和詳情頁將商品添加到購物車。
• 用戶登陸後，首頁，詳情頁，列表頁顯示登陸用戶購物車中商品的數目。
• 購物車頁面：對用戶購物車中商品的操做。如選擇某件商品，增長或減小購物車中商品的數目。

因此這個模塊就只有一個頁面：

• 購物車頁面

4.訂單相關

• 提交訂單頁面：顯示用戶準備購買的商品信息。
• 點擊提交訂單完成訂單的建立。
• 用戶中心訂單頁顯示用戶的訂單信息。
• 點擊支付完成訂單的支付。

因此這個模塊就只有一個頁面：

• 訂單頁面

 

####################################################################

 

架構設計的注意點：

 

注意1：先後端問題

上面都是講的前段的內容，可是除此以外還有後臺管理的頁面，添加商品，管理我網站上面要顯示的內容，

實際的公司裏面開發項目，django有後臺管理的模塊，能夠管理頁面，可是像電商大型的項目，不會使用這個django後臺，會專門開發後臺管理頁面，

那django的後臺何時用？有一個項目你想要很快的作出來，就可使用這個django後臺先搭起來，

或者一個博客，或者作一個新聞類型的網站，你可使用它的後臺管理頁面，

這個項目就是使用的django的後臺管理功能，

 

注意2：數據庫使用問題

實際開發中都會使用mysql數據庫，這是使用最多的，

可是若是用戶量很是大，會把經常使用的數據，或者是頁面放到緩存裏面，爲何？好比首頁，首頁的商品信息是數據庫來的，可是展現的商品很長時間才動，

若是訪問人很是多，好比1萬人就要從數據庫查1萬次，就太頻繁了，因此會把頁面放到緩存裏面，放到緩存的服務器裏面，

並且用戶來了以後須要存用戶的session信息，若是用戶很是大，你要不停的查數據庫，因此還須要一個session的服務器，提升它的效率，

使用到的緩存數據庫就是Redis數據庫，內存型的數據庫，這就是最經常使用的場景，使用Redis數據庫，做爲咱們的緩存服務器，和session服務器，

 

注意3：異步任務處理問題

除此以外還須要異步的任務處理，好比註冊以後，發送給用戶一個郵件，這種比較耗時，就須要一個異步的任務處理，使用celery來異步處理這種耗時的任務，

註冊以後，交給celery發郵件，不該該用戶操做頁面，該幹什麼幹什麼，就體驗很好，

 

注意4：分佈式文件存儲問題

除此以外還涉及到商品的圖片，對於一個大型的網站，涉及到不少的商品圖片，django自己上傳圖片，它的效率是很低的，

在咱們的這個項目中，就再也不使用django默認的這個圖片上傳的處理，咱們使用一個分佈式文件儲存系統，幫助咱們存儲圖片，

這個系統叫fastdfs，這個分佈式文件存儲系統是一個淘寶的使用的一個系統，後來開源了，後來不少的電商網站就使用這個系統，

 

######################################################################################

數據庫設計

這是很是重要的一環

用戶表：ID，用戶名，密碼，郵箱，激活標識（表示用戶是否被激活），權限標識（由於你要把管理員和普通用戶放在一張表）

地址表：ID，收件人，收件地址，郵編，聯繫方式，是否默認（默認收貨地址），用戶ID（和用戶是1對多的）

商品SKU表：ID，名稱，簡介，價格，單位，庫存，銷量（不放這也能夠計算出來，可是按照人氣排序，就是使用銷量，能夠減小關聯的操做，就不用統計了，）

　　　　　　商品詳情，圖片（仍是要記錄一張，不然每次都要連表查效率低，這就是以空間換時間），狀態（上下架），SPUID，種類ID，

商品SPU表：ID，名稱，詳情，

商品種類表：ID，種類名稱，logo（這是種類前面的小logo），圖片（這是種類的展現圖片）

商品圖片表：ID，圖片，SKUID（和商品一對多，一個商品有多個圖片）

首頁輪播商品表：ID，SKUID（你是輪播的哪個商品），圖片（這是一個大banner），index（能夠控制展現的順序）

首頁促銷活動表：ID，活動圖片，活動的url地址（跳轉的可能不是一個商品，而是一個活動地址），index（能夠控制展現的順序）

首頁分類商品展現表：ID，SKUID（我要展現哪個商品），種類ID，index（能夠控制展現的順序），展現標識（好比1是展現成圖片，0是展現成標題）

購物車功能：Redis實現購物車功能，並不打算建一個表，由於每次點擊加商品和減商品，都要操做數據庫，驗證庫存，這樣可使用Redis緩存，

　　　　　　可是我有疑問，爲何每次都要去校驗呢？體驗好，否則就是你要在提交的時候才知道庫存不足，

　　　　　　至於怎麼使用Redis放數據，實現購物車的功能，後續再說，

訂單信息表：ID，訂單ID，收穫地址ID，用戶ID（誰下的單），支付方式，商品的總數目（根據運營需求來，加上能夠利於分析數據，不加也能夠），

　　　　　　總金額（能夠不加，可是加上有利於分析數據），運費，支付狀態，訂單建立時間，

訂單商品表：ID，訂單ID，SKUID，商品數量，商品價格（由於價格會變更，因此必定要記錄），訂單和商品是一對多，一個訂單能夠多個商品，評論

用戶瀏覽歷史記錄：仍是保存在Redis數據庫中，

因此設計表的時候有一個套路，就是一旦發現有一對多的關係，就要分紅兩個表，

表在設計以前是須要仔細斟酌的，不可能今天該，明天該，不會頻繁變更，

-------------------------------------------

電商裏面SKU與SPU概念

SPU = Standard Product Unit (標準產品單位)
SPU 是商品信息聚合的最小單位，是一組可複用、易檢索的標準化信息的集合，該集合描述 了一個產品的特性。通俗點講，屬性值、特性相同的商品就能夠稱爲一個 SPU。
例如:iphone7 就是一個 SPU，與商家，與顏色、款式、套餐都無關。

SKU=stock keeping unit(庫存量單位)

SKU 即庫存進出計量的單位， 能夠是以件、盒、托盤等爲單位。
SKU 是物理上不可分割的最小存貨單元。在使用時要根據不一樣業態，不一樣管理模式來處理。 在服裝、鞋類商品中使用最多最廣泛。
例如:紡織品中一個 SKU 一般表示:規格、顏色、款式。

舉例：iPhone7是一個SPU，可是白色iPhone7是一個sku，黑色iPhone7也是一個sku，

 ######################################################################################

項目框架搭建

我須要本身實現這個項目搭建

1，新建django項目，使用命令行建立沒有templates這個文件夾，須要手動建立，

2，一個模塊就有一個應用app，因此有四個app，

3，項目配置：app配置，數據庫配置，語言時區配置，templates路徑配置，static路徑配置，

查看Django的版本，能夠直接在控制檯進入Python解釋器，輸入print（django.VERSION),或者輸入python -m django --version，均可以實現查看Django版本。

D:\AI\dailyfresh>python -m django --version

File——Setting——project：項目名——project interpreter——雙擊Django，勾選Specify 再右邊下拉選須要的版本，最後Install Package就能夠了

4，開始url編寫對應關係，這個url的地方最好使用反向解析的方式，這樣改動路徑不用大量更改代碼

5，定義一個db/base_model.py的文件，一個數據表的基類，給每個表增長三個字段，

6，按照一個富文本編輯器，pip install django-tinymce

7，配置文件加上一句：

# 加上這句表裏的字段都是同樣的，就是不在使用django提供的auth_user表，並且使用本身的，
AUTH_USER_MODEL = 'user.User'

這樣基本的項目框架就搭好了，

 

注意：

在新版本Django2.x中，url的路由表示用path和re_path代替，

模塊的導入由django1.x版本的

from django.conf.urls import url,include

變成如今的Django2.x中的

from django.urls import path, re_path, include