python-django电商项目_20191114

Posted 技术改变命运Andy

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了python-django电商项目_20191114相关的知识,希望对你有一定的参考价值。

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,

 

以上是关于python-django电商项目_20191114的主要内容,如果未能解决你的问题,请参考以下文章

python-django项目-Linux系统相关研究_20191117

python-django-类函数__str__ 函数

python-django-类函数__str__ 函数

Python-Django框架研究_登陆查看数据添加数据_20191104

python-django-自定义分页

python-Django web项目创建