一、业务流程图
- 业务流程图是原型、数据库设计的基础，它能告诉我们整个项目究竟是做什么，大致有什么功能，需求是什么。
二、原型
- 以下是我在经历三天半的原型设计所总结出来的一些注意事项：
- 想清楚需求是什么，并记录下来
- 遇到自己无法设计出来的情况，可以去参考别人的作品
- 在设计原型的时候，要想清楚每一步部分原型间的关系，先做什么，接着做什么，最后做什么。
- 举个例子：比如cms中关于商品这一部分：
- 我们要知道两点关键点：（这是参考别人的作品加上自己的理解总结出来的）
- 1）、同一商品，因规格不同，其价格、图片、库存就会不一样；
- 2）、规格、品牌是基于商品类别去筛选的。
- 因此，我们在设计cms中关于商品这一大块时，就知道必须先有商品类别，然后再有规格、品牌、最后才是商品！这也告诉了我们关于商品这一部分原型间的关系，即原型设计的先后顺序！
- 当遇到设计思路有阻碍或者想到了什么新颖的设计想法时，都必须及时记录下来，方便自己去总结或者修改自己的作品
三、数据库设计
3.1 ER 图设计
- 完成初稿后，我涌现了一堆的问题：
- 用户购买商品，肯定会先加入购物车，结算后才会生成订单，那么这个在
ER图中应该怎么表现？订单、购物车能不能做实体？- 商品的话，是会有分类的，所以商品类别可以作为一个实体，但是商品也会有是推荐商品、特价商品的情况，那么此时需不需要将推荐商品、特价商品的分离出来作为一个实体呢？还是直接把是否为推荐商品、是否为特价商品作为商品实体的一个属性呢？ 个人想法是：不同的用户或许需要推荐不同的商品，如果将其隔离出来，会便利许多。
- 不同的商品有不同的规格、颜色等属性，那这些应该是怎么处理呢？我的想法是，例如：如果是衣服，那么其可选尺寸我打算存为
S&M&L&XL&XLL等格式，但是后来想一想，不同的尺寸或者颜色的话，其库存量是不一样的，那这个应该怎么去设计ER图？- 用户会浏览商品，那么“浏览”能不能成为用户和商品间的关系？如果用户浏览了一样商品，是否需要将其记录下来？我觉得这个也是一个数据，用来研究用户对哪些商品感兴趣。如果真的要存储这些数据的话，不可能用户每浏览一样商品就操作一次数据库，这会不会先存储缓存里，等到某一个适当的时机（例如：顾客退出登录）再一次将数据存储在数据库里
下面是向师兄请教后，自己对问题的总结以及一些扩展：
- 订单、购物车可以做实体
- 不同规格、不同颜色的衣服作为不同的商品去处理，并且应该多加一个库存表
- 推荐商品之类的是针对用户定制的，所以是否为推荐商品不能作为商品的属性，因为这样是无法区分哪个商品是推荐给用户的； 推荐商品可以结合用户的购物车、用户所收藏的商品去做【个人觉得这里就要有大量的数据分析、研究、计算】
- 一般浏览记录都放在
cookie里 ，如果做持久化，记录量将会十分大。- 订单、商品、库存三者关系：订单关联商品，库存关联商品
- 上面的
ER图还有缺陷的：
- 需添加多一个订单明细表，每一个订单里面有的商品数据，应该存储在订单明细表里，而不是订单表，订单表只是存储总数量、总价这些与商品数据无关的数据。【即：订单明细表是具体的，订单表是简单的】
- 也需添加多一个购物车明细表，理由与上述差不多。
- 对于订单明细来说，只需引入了商品编号，通过商品编号获取商品信息，购物车明细表也是一样的，其他类似的表也是一样。
- 对于商品的价格来说，我只把原价、优惠价作为商品的属性，却忽略了其扩展性，如果遇到一些活动，商品要打折之类的，就完了！所以我在这里添加多一个商品价格表。
- 不是结算才生成订单，而是下单就生成订单，因此，订单应该有状态的：未支付， 已支付， 已取消， 已过期， 已退款； 同样的，商品也是有状态：未支付， 已支付， 已取消， 已过期， 已退款；收藏的商品也是有状态：过期，未过期
- 上面的
ER图是设计出来了，但是我却严重忽略了一点，这个ER图并没有基于原型去设计，而是直接将ER图脱离原型去设计，这是我犯的一个超级严重的错误！
- 下面这张图片，是结合了上述所讲的一些注意问题以及原型而做出来的终版
ER图！
四、总结
- 在做开发的时候，【业务流程图 ===》 原型设计 ===》 数据库设计（ER图设计 ===》 数据库的相关操作）】这一顺序不可乱！
- 例如：原型没有设计好就急着去设计
ER图，简直是自找麻烦！
- 数据库设计，一般要想到联系，从
id入手，因为这个是唯一标识