设计以以下为工具讲起
1、PHP为开发语言；
2、基于Laravel框架；
3、MySQL为数据存储；
电商的可变性与孩子的心情一样，变化极快，所以在设计之处就要想好大部分的功能接入及开发，尽量减少重构次数。对老板来说节约成本，对程序员来说“珍惜生命”
数据表
前期业务简单时，我们可以将数据表设计为下列的样子
用户表
考虑到多种登录方式，应在数据表中涉及到微信的openid,unionid,支付宝、QQ的用户token等，这些要在前期就涉及进去，因后期用户量大了之后加一个字段简直是噩梦,用户状态status也必不可少，比较人也是分好坏，其次就是创建时间，登录时间等，用户表与用户信息表绝逼是绑定关系，这就不多言了。
收货地址表
收货地址与用户是一一相对的，在设计上增加需要的字段即可，例如 收货人、收货人手机号、城市、详细地址等
银行卡表
用于用户提现的业务等，大致将银行卡所需的信息记录即可，例如持卡人、卡号、归属银行等
购物车表
为何单独建这个表，也是又一定原因的，正常只需要member_cart_item表即可，根据实际下线的业务场景，正常购物到超市需要拿一个购物车，但这个购物车并非属于你，你使用之后，需要归还，他人可继续使用，将购物车公开化，并不是将购物车商品公开化。业务场景比较窄，例如京东到家和京东商城一样（我只是举例，并不清楚他们怎么做的），购物车不通用，那如何区分呢，是应该在购物车上区分还是在购物车商品上区分？我想你已经清楚了
购物车商品表
这块需要提的一点是 [并不是所有表的设计都是互相绑定,互相依赖的]，就例如购物车商品表，不仅仅将商品编码存储在内，还要将商品价格，商品的简介以及商品的规格(既SKU)存储，不能因卖家下架商品，而查询不到商品的存在，比较一切以用户为主，用户是上帝的原则，不能让商品悄悄的就消失了吧。所以在做购物车商品表查询时，切记不要使用join或者表关联查询
用户搜索历史表
用户搜索的记录是一定要有的，为了未来的数据分析，智能推荐做准备，毕竟现在是信息共享的时代嘛～
数据记录
有很多场景，都要将标题呀，内容呀直接存储，类似与收藏的店铺和商品，无论卖家怎么做，用户购物车，订单不能动，这是基准。
<hishop（www.hishop.com.cn）是国内知名企业级电商平台提供商，为企业级商家提供最佳的系统开发（多种模式电商平台搭建：B2B/B2B2C/B2C/O2O/新零售等）、供应链系统搭建及电商行业解决方案服务>
文章来源：网络整理
