根据前台设计数据库--产品展示篇2
2016-09-13 20:17
239 查看
前面在根据前台设计数据库--搜索篇中就想好了要将产品的具体分类信息放到 mongodb 中,以 json 格式存储,但是当时没有详细思考具体的格式,只是一个简单的规划,现在就来针对这个规划做一个详细的分析。
第一点是对前面的一个推翻,前面我希望存储的格式是这样的:
。
当时这样写是没有考虑需求,只是单纯的完成存储过程,所以现在是时候考虑不同情况下这个存储结构该怎么设计了。
一般模式:
这里只有最简单的需求,一款产品的具体分类只有两级,多的还可以有3级,4级等,这些都不是问题,加一个变量就可以搞定了,接下来就是一些特殊需求了:
限购,每次可以购买产品的数量是一定的,即使库存有这么多。
最低购买数量,每次只有数量达到一定程序才会产生订单。
针对购买数量具有不同的折扣。
预定功能,需要缴纳一定的押金才会产生订单。
如果只是存储的话还是比较简单的,但是针对控制器读取这些数据之后要怎么处理就需要为存储设置一个默认的规则了,我定下的规则是这样的:
公用变量1 "model":处理的模版,根据前面设想的情况有 1:传统模式,2:限购模式,3:最低数量购买模式,4:预定模式,
而且后面如果有别的模版只需要增加处理器就可以了
公用变量2 "_id":跟MySql连接的关键字,即为ProductID
公用变量3 "Category_Level":下面的分级的层数
公用变量4 "store":库存量
公用变量5 "salary":一个月的销量,mongodb没有像MySql那样的事件可以定期自动清理,所以需要人手工去清除
1:传统模式存储数据模版:
2:限购模式 和 3:最低购买数量是一致的,所以这里写在一起了
在模版1的基础上添加几个变量
"model";2表示该模版需要用针对模版2的控制器去解析,多了两个变量,min和max,表示最少min件,最多max件,这里的限制不单单是单笔订单,而是该用户总的下单数量,实现的原理下面再讲。
接下来的问题就是这些模式能否复用,答案是可以的,先统一用模式1处理,接着检查模式后面是否还有其他模式,如果有的话就再单独处理那个模式下特有的字段值。接下去就是考虑控制器的处理以及在视图区域的显示了。(thinkphp 与 mongodb 的连接可以看这里:thinkphp 3.2.3连接mongodb数据库)这个问题到具体写产品展示页的时候再设置。
第一点是对前面的一个推翻,前面我希望存储的格式是这样的:
{ "product_id": [{ "red": [{ "XL": [ { "store": 60 }, { "salary": 50 } ] }] .......其他颜色情况.......... }] }这样当然是行不通的,因为我没存 ProductID
。
当时这样写是没有考虑需求,只是单纯的完成存储过程,所以现在是时候考虑不同情况下这个存储结构该怎么设计了。
一般模式:
这里只有最简单的需求,一款产品的具体分类只有两级,多的还可以有3级,4级等,这些都不是问题,加一个变量就可以搞定了,接下来就是一些特殊需求了:
限购,每次可以购买产品的数量是一定的,即使库存有这么多。
最低购买数量,每次只有数量达到一定程序才会产生订单。
针对购买数量具有不同的折扣。
预定功能,需要缴纳一定的押金才会产生订单。
如果只是存储的话还是比较简单的,但是针对控制器读取这些数据之后要怎么处理就需要为存储设置一个默认的规则了,我定下的规则是这样的:
公用变量1 "model":处理的模版,根据前面设想的情况有 1:传统模式,2:限购模式,3:最低数量购买模式,4:预定模式,
而且后面如果有别的模版只需要增加处理器就可以了
公用变量2 "_id":跟MySql连接的关键字,即为ProductID
公用变量3 "Category_Level":下面的分级的层数
公用变量4 "store":库存量
公用变量5 "salary":一个月的销量,mongodb没有像MySql那样的事件可以定期自动清理,所以需要人手工去清除
1:传统模式存储数据模版:
{ "model":1 "ProductID":ProductID, "Category_Level":3, "Category_Level1":[ "Category_Level_2":[ "Category_Level_3":prices, "store":values, "salary":values, ] ] }下面举个具体例子:
{ "model":1 "_id":1, "Category_Level":2, "price":123, "XL":[ {"红色":123,"store":9,"salary":1}, {"浅绿":145,"store":10,"salary":2}, ], "L":[ {"红色":123,"store":11,"salary":3}, {"浅绿":145,"store":12,"salary":4}, ], "M":[ {"红色":123,"store":13,"salary":5}, {"浅绿":145,"store":14,"salary":6}, ] }表示现在产品号为1的产品一般售价为123,XL号的红色售价123,库存9,销量1,浅绿色的售价145,库存10,销量2,这样就十分直观了。其中的 _id 就是ProductID
2:限购模式 和 3:最低购买数量是一致的,所以这里写在一起了
在模版1的基础上添加几个变量
"model";2表示该模版需要用针对模版2的控制器去解析,多了两个变量,min和max,表示最少min件,最多max件,这里的限制不单单是单笔订单,而是该用户总的下单数量,实现的原理下面再讲。
{ "model":2 "_id":1, "Category_Level":2, "price":123, "min":1, "max":5, "XL":[ {"红色":123,"store":9,"salary":1}, {"浅绿":145,"store":10,"salary":2}, ], "L":[ {"红色":123,"store":11,"salary":3}, {"浅绿":145,"store":12,"salary":4}, ], "M":[ {"红色":123,"store":13,"salary":5}, {"浅绿":145,"store":14,"salary":6}, ] }4:预定模式
{ "model":2 "_id":1, "Category_Level":2, "price":123, "XL":[ {"红色":123,"store":9,"salary":1,"cash_pledge":50}, {"浅绿":145,"store":10,"salary":2,"cash_pledge":50}, ], "L":[ {"红色":123,"store":11,"salary":3,"cash_pledge":50}, {"浅绿":145,"store":12,"salary":4,"cash_pledge":50}, ], "M":[ {"红色":123,"store":13,"salary":5,"cash_pledge":50}, {"浅绿":145,"store":14,"salary":6,"cash_pledge":50}, ] }多一个"cash_pledge"的字段表示押金(这里不考虑缴纳定金之后多少天过期的问题)
接下来的问题就是这些模式能否复用,答案是可以的,先统一用模式1处理,接着检查模式后面是否还有其他模式,如果有的话就再单独处理那个模式下特有的字段值。接下去就是考虑控制器的处理以及在视图区域的显示了。(thinkphp 与 mongodb 的连接可以看这里:thinkphp 3.2.3连接mongodb数据库)这个问题到具体写产品展示页的时候再设置。
相关文章推荐
- 根据前台设计数据库--搜索页篇
- 根据前台设计数据库--首页篇
- 请根据下面需求,按照数据库设计步骤绘制符合第三范式的E-R图和数据库模型图
- 中小型超市系统中的分类/产品属性/扩展属性的数据库设计
- 根据图论构建可量化评估的产品设计模型-类图(Like Graph)
- 群发“站内信”根据不同用户量,不同的数据库设计原理
- 群发“站内信”根据不同用户量,不同的数据库设计原理
- 如何设计动态(不定)字段的产品数据库表?--淘宝多产品属性字段设计方法
- 根据数据库获取新的序列号传到前台
- 电子商务网站 数据库产品表设计方案
- 关于无限级分类数据库表结构设计问题,遍历某分类下所有产品 效率 (两张表) (一张表)
- 数据库中根据数据一对一,一对多,多对多关系设计
- 请各位大虾们帮帮小弟,谢谢!一个关于产品搜索数据库设计思路的问题
- 中小型商城系统中的分类/产品属性/扩展属性的数据库设计
- 目录树的数据库设计、java后台读取,以及前台javascript的显示
- 中小型商城系统中的分类/产品属性/扩展属性的数据库设计
- 牛腩购物9 用户表设计/动软生成器/金钱字段decimal(18, 2)/ 注册的时候的前台js判断/后台代码判断/正则表达式软件/RegexBuddy/设置数据库字段的唯一性约束/如何获取控件在前台html的id值/如何将C#的后台正则换成js的正则
- 中小型商城系统中的分类/产品属性/扩展属性的数据库设计
- 代码开发:数据库编程,前台设计,后台编码,一些注意点
- 产品经理如何根据产品所处的阶段选择设计方案?