|
马上注册,结交更多好友,享用更多功能,让你轻松玩转社区。
您需要 登录 才可以下载或查看,没有帐号?立即注册
x
支持多种存储引擎。数据
近期看了idilent的文章《利用面向工具手艺办理商品打折成绩》,文后有读者提出请求:假如分歧商品的扣头分歧怎样办?大概有买一百送五十这类体例,或分歧会员品级的扣头分歧。怎样处置?”idilent以为打折这个成绩并非可以经由过程一个数据库的字段就能够办理的。有分歧的会员,分歧的产物,分歧的发卖企图,而这些也是在一直的稳定化和增添的。而会员和产物的打折,和店庆等打折,固然都是扣头,可是很难笼统成数据库中的一个字段大概几个字段,不利用程序办理,而但愿只是经由过程改动数据库中的数据,在今朝阶段完成起来大概还对照坚苦。
之前我曾介入过一个影碟出租发卖办理体系的项目开辟,卖力个中的架构计划和数据建模事情,只管最初该项目因为某些客不雅缘故原由而被保持,可是该项目中也有打折优惠这方面的功效需求,我也思索过这一块的数据建模。实在,我们能够把商品发卖打折如许的商务划定规矩分化成几个部分,剖析各个部分之间的干系,从中找出关头点,再将其泛化数据建模,便可完成让用户本人界说打折划定规矩。上面入手下手剖析商品发卖打折的贸易划定规矩:
一套商品发卖办理信息体系,一定存鄙人面两个实体:主顾,商品,打折这类贸易划定规矩必定是环绕着这两个实体和互相间的干系而制订的。回忆我们的购物履历,打折的需求应当能够分为三种:
1)对特定商品的扣头一样平常有以下几种情形:按售价举行必定百分比的打折;原价->特价(某个工夫段内举行的)的打折;绑缚优惠发卖(如购置某一(几)种商品后便可按较低的代价或扣头购置另外一(几)种商品)。
2)对主顾的的打折体例一样平常接纳会员制,便是按会员品级在交费时间接授与必定的扣头优惠,大概在会员积累消耗必定金额后赐与必定比例的返点优惠,该体例必要主顾打点会员卡之类的身份标识卡。
3)对总额的打折体例通常为主顾消耗后送出的限制最初利用刻日的代金券。
注重到下面三年夜类扣头体例分化开来,都离不开商品,以是这三种打折体例都是商品的共有属性,应当回进到商品表中。别的,一样平常年夜型超市多具有多个分店,并且大概呈现各个分店的打折划定规矩略有分歧的情形,下面的三种打折划定规矩得同响应的分店逐一对应。最初,数据建模大抵以下:
商号表(Shop)
称号范例束缚前提申明
shop_idint无反复商号标识,主键
shop_namevarchar(40)不同意为空商号称号
shop_addrvarchar(80)不同意为空商号地点
……
商品种别表(Ware_type)
称号范例束缚前提申明
type_idint无反复商品种别标识,主键
type_namevarchar(20)不同意为空商品种别称号
fatherint不同意为空该种别的父种别标识,假如是顶节点的话设定为某个独一值
layerchar(6)限制3层,初始值为000000种别的先序遍历,次要为削减检索数据库的次数
商品表(Ware)
称号范例束缚前提申明
ware_idint无反复商品标识,主键
ware_typeint不同意为空所属商品种别,和Ware_type.type_id联系关系
ware_namevarchar(40)不同意为空商品称号
buy_pricefloat不同意为空进货价
sell_pricefloat不同意为空发卖价
d_typechar(1)不同意为空商品打折体例
m_typechar(1)不同意为空会员打折体例
has_couponbit默许值为0是不是有代金券
……
申明:
①d_type用来分辨该商品的商品打折体例。"0"暗示该商品无商品扣头体例;"1"暗示该商品接纳百分比打折体例;"2"暗示该商品接纳特价打折体例;"3"暗示该商品接纳绑缚打折体例,是绑缚打折划定规矩中的必购商品;"4"暗示该商品接纳绑缚打折体例,是绑缚打折划定规矩中的允购商品。
②m_type用来分辨该商品的会员打折体例。"0"暗示该商品不介入会员扣头盘算;"1"暗示该商品接纳会员百分比扣头体例;"2"暗示该商品接纳会员卡积累消耗返点扣头体例。
③has_coupon用来指明该商品是不是有代金券。"0"暗示该商品无代金券;"1"反之。
商品库存表(Store_table)
称号范例束缚前提申明
store_idint无反复库存标识,主键
shop_idint不同意为空商号标识,和Shop.shop_id联系关系
ware_idint不同意为空商品标识,和Ware.ware_id联系关系
numberint默许值为0商号库存数目
unitvarchar(10)不同意为空发卖单元
商品扣头划定规矩表(Discount)
称号范例束缚前提申明
idint无反复扣头划定规矩标识,主键
s_idint不同意为空商号标识,和Shop.shop_id联系关系
w_idint不同意为空商品标识,和Ware.ware_id联系关系
d_valuefloat不同意为空打折数值,用来纪录百分比或特价
enddatedatetime不同意为空该划定规矩的停止日期
numberint同意为空该划定规矩所同意的最年夜销量
unitvarchar(10)同意为空发卖单元
商品绑缚打折表(Bind_discount)
称号范例束缚前提申明
b_idint无反复绑缚打折划定规矩标识,主键
shop_idint不同意为空商号标识,和Shop.shop_id联系关系
1st_wareint不同意为空必购的商品标识的汇合,和Ware.ware_id联系关系
min_reqint默许值为1最小必购数目
2nd_wareint不同意为空允购的商品标识的汇合,和Ware.ware_id联系关系
max_buyint默许值为1最年夜允购数目
d_typechar(1)不同意为空打折体例,是百分例如式仍是特价体例
d_valuefloat不同意为空打折数值,用来纪录百分比或特价
enddatedatetime不同意为空该划定规矩的停止日期
numberint同意为空该划定规矩所同意的最年夜销量
unitvarchar(10)同意为空发卖单元
申明:1st_ware用来纪录必购商品的汇合,min_req暗示在必购商品汇合内的最小购置数目。2nd_ware用来纪录允购商品的汇合,max_buy暗示到达必购商品的最小购置数目后,所同意购置的允购商品的最年夜允购数目。举例申明:某绑缚发卖划定,但凡购置了某系列商品中的恣意1件,便可按特价购置允购商品中的恣意1款1件。这类促销体例人人都见过吧?买二送一不外是个中的惯例而已。
会员品级表(Member_type)
称号范例束缚前提申明
type_idint无反复会员品级标识,主键
s_idint不同意为空商号标识,和Shop.shop_id联系关系
type_namevarchar(10)不同意为空会员品级称号
t_valuefloat不同意为空打折百分比或积累消耗返点数
conditionfloat不同意为空到达该品级所需积累的消耗额
会员表(Member)
称号范例束缚前提申明
m_idint无反复会员标识,主键
m_namevarchar(10)不同意为空会员姓名
type_idint不同意为空会员品级标识,和Member_type.type_id联系关系
scorefloat默许值为0会员积累的消耗积分
……
代金券表(Coupon)
称号范例束缚前提申明
c_idint无反复代金券标识,主键
c_namevarchra(20)不同意为空代金券姓名
c_valuefloat不同意为空代金数额
conditionfloat不同意为空所需现金消耗
enddatedatetime不同意为空代金券的停止日期
固然,因为自己所认知的打折体例其实不周全,也没有和相干的营业人士深切会商过这方面的成绩。以是,下面的数据建模其实不能包管掩盖实际商品发卖中的的一切打折体例。不外,我信任,接纳下面的数据建模来界说打折划定规矩,掩盖率仍是在90%以上的。依据95/5划定规矩,只需给我充足的工夫,再加上专业人士的帮忙,不计开辟本钱的话,100%的掩盖率是能够到达的^-^
最初,因为每张购物清单都是由商品构成,而每种商品的扣头的盘算划定规矩其实不必定完整不异,以是我以为在用面向工具的计划办法,计划盘算扣头的组件时,接纳粉饰(Decorator)形式对照合适。
从理论上讲,完全可以为数据表里的每个字段分别建一个索引,但MySQL把同一个数据表里的索引总数限制为16个。 |
|