根据前台设计数据库--产品展示篇2

前面在根据前台设计数据库--搜索篇中就想好了要将产品的具体分类信息放到 mongodb 中,以 json 格式存储,但是当时没有详细思考具体的格式,只是一个简单的规划,现在就来针对这个规划做一个详细的分析。

第一点是对前面的一个推翻,前面我希望存储的格式是这样的:

{
    "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数据库)这个问题到具体写产品展示页的时候再设置。




  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值