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