PHP[PHP] B2B2C商品模块数据库设计

 

 

把每个规格都排列组合一下,就是最终的sku

type_spec(类型标准关联表)

原则颜色

2.善用分裂的存储引擎,MySQL有多种不相同的存储引擎,InnoDB,Aria,MEMORY依照须要给差异的表拔取不相同的储存引擎,比如要帮衬transaction的话用InnoDB等;

标题

 

对于三种设计艺术,个人精通为

成本价

  1. 把原来的横表转化为纵表存储属性,即

商品规格种类化,例如:Array ( [222] => 蓝色 )

b.
首页突显产品列表时候就存在要突显出差距出品性能情状,采纳方案2来做。当大家处理的是一个product
list的时候,由于存在数据表本身的涉及场景,用方案1会比麻烦,也潜移默化属性。

顶部提到版式

一级地带id

运费模版

二级地区Id

集团分类id 首尾用,隔开

腾讯网:mysql的数据库设计到底该不应该加约束

是不是免运费

 

a.
对于首页打开就必须求可以神速查询出来的特性,而且这么些属性本身各样产品差别不大。而对此差异大的性能基本都是指向特定一个出品查询。可以应用方案1来做。

一流地点id

颜色规格id     ——关联商品表的水彩id,显示在详情页部分

 

性能名称

自身在构思一个题目,电商网站的数据库设计,紧如果货物归类,商品的详情(不相同的货色有两样的熟悉,比如衣服有颜色、尺码,然则电脑有CPU、内存、显卡等标准化),库存表(一个店铺里面某个商品有两样的标准化,分裂的规格有例外的库存数据),那里面怎么规划。

  1. 保持原来横表设计思路,不过弹性字段含义单独元数据表存储

二维数组的key对应规范值表的id,value对应规范值表的称谓

 

spec_value (商品规格值表)

品种id    
————添加商品时选用分类,根据项目id,类型规格表,关联规格id,取出规格

货物状态

产品表:(product_id, product_name, product_class, prop1, prop2, ….
propn)

类型id

先是来说对于那种情景有二种设计方法,那二种办法都能够满意扩充性需求

把尺度名称数组连串化后存入这些字段

type(商品类型表)

 

销售数据

项目id              ————关联类型表,并涉嫌类型上面的性能

规格id

产品表:(product_id, product_name, product_class)

 

货物价位

折扣

运费模版名称

是还是不是免运费

那款衣裳,有黑白七个颜色,小中大特大多个尺码,颜色和尺寸就是他的五个原则,每个颜色和尺寸排列组合,组成最后的sku。

简易明白一下,SPU是基准产品单元,区分类别;SKU是库存量单位,区分单品;商品特指与集团有关的货品,可对应多少个SKU。

 

是或不是推荐

好评星级

分类id

率先,搞领悟商品与单品的分别。例如,iphone是一个单品,可是在天猫上当很多商店同时出售这么些产品的时候,iphone就是一个商品了。

品牌id

 

规格值id

(product_class , prop1_name ,prop2_name, ….. propn_name)

 

 

attribute_value(商品属性值表)

标准化值字段

 

店家自定义编号

key部分是不会变的,value部分是可以被店家填商品的时候修改

iphone6是一个spu

排序

 

属性id

上边这个对SQL Server一类轻量级的数据库也就大多了
但对此Oracle DB2那种重量级数据库
再有内存管理优化
太久不做时代部分理不清头绪了
而后想起来能补再补

 

新浪:有何样常见的数据库优化措施?

规范1-颜色,包括褐色白色,土豪金

货物库存

规格id

老黄的实验室:

排序

市场价

父级id

货物主图        
————只保留上传后图片的文书名,全路线通进程序拼接,更灵活

kentzhu:

数据库物理层:
1)数据库系统软件应该尽可能跟数据文件分置差距存储设备
2)假若可能数据库临时空间、log尽量使用便捷存储设备
3)数据文件应该依照现实选拔必要分置不相同存储设备进步读取功效
4)数据文件使用RAID既维持数据安全又便宜性能

货物公共id

属性值名称

Rocky:

key对应的是规格表的id,value对应规格表的称谓

属性id

3.表很大的时候,做分片。

category(商品分类表)

规则名称字段

把标准名称对应的值数组连串化后存入那些字段

是还是不是默许         ——是还是不是是封面上出示的图形

商品充裕时间

知乎:产品 SKU 是怎么看头?与之有关的还有何?

 

goods_image(商品图片表)

商品归类名称————适度冗余,减少关联表

商品:天猫叫item,京东叫product,商品特指与商家有关的商品,每个商品有一个小卖部编码,每个商品下边有三个颜色,款式,可以有三个SKU。

合营社id     ————差别的铺面,规格值分裂

二级地区id

货物主图

货物状态         ————0 下架,1 常规

 

分类名称

iphone6为例:

规格id

 

 

 

商品品牌Id

合作社分类id 首尾用,隔开

 

 

规格2-容量,包含16G,32G,64G,128G

审批败北原因

货物归类id

joylisten:

 

货物属性

 

例如:Array ( [1] => Array ( [222] => 蓝色 [224] => 绿色
[225] => 梅红 [226] => 黑色 ) ),

高校派会告知你在设计的时候把相应有的羁绊都添加

店铺id

一维数组的key对应的是属性表的id,二维数组的name对应属性表的称呼,二维数组的第三个要素key对应属性值表id,value对应属性值表的称谓

分拣名称

是否开具增值税发票

 

货物内容

商品审核

谢龙:

货物编辑时间

主键约束一定要加,非空约束必不可少。外键最好不要加,除非是涉嫌极多,业务最好错综复杂的时候才方可设想加外键。

货物宣传词

例如:Array ( [1] => 颜色 ),

 

 

规范名称

新浪:关于电商网站数据库的设计?

丰裕分化条件的货品,生成多条商品信息,sku是例外的,

商品名称

运费模版id

货物公共id

是或不是出示

一款衣裳,是一个spu

 

颜色规格id     ————关联商品图片表,显示颜色图片

类型id

SKU=stock keeping unit(库存量单位),SKU即库存进出计量的单位,
可以是以件、盒、托盘等为单位。在衣物、鞋类商品中应用最多最普遍。
例如纺织品中一个SKU经常表示:规格、颜色、款式。

数据库应用层
以此太多了
首先Modeling要合理
这一个太主要
利用设计不创建再怎么优化、哪个人来优化也只是死马当活马病

附带是代码中的SQL语句优化
比如说查询尽量使用索引
尽量不要做全表扫描
慎用子查询和Union All
多表join时尽量用小表去join大表
(注每个数据库厂商对join的处理不完全等同
那里的优化应该参照数据库厂商的用户手册)
等等等等

 

货物宣传词

规格排序

SKU是大体上不可分割的纤维存货单元。在运用时要按照不一致业态,不同管
理情势来处理。比如一香烟是50条,一条里有十盒,一盒中有20支,这个单位就要依照区其他急需来设定SKU。

不合法原因

点击数据

货物图片id

第一维的key对应规范表id,

而执行派得出的定论是主键一定加,非空约束尽量加,外键最好凭借于程序逻辑,而不是数据库,从而更好的搂抱变化,急迅响应,数据库也会有绝对较好的习性

货物锁定

 

商品审核情形

惑春秋:

spec (商品规格表)

商品SKUid

在电子商务里,一般会波及如此多少个词:商品、单品、SPU、SKU

原则和属性的不一样是,规格影响价格,属性不影响价格,在货物分类页的是性质筛选

 

底层关联版式

 

分类名称

讲评数据

分类id

何明璐:

排序

关键字

条件值名称

 

是还是不是推荐

分类id

诸如非空约束,外键约束等。因为自身来看大家商家的DBA在筹划数据库结构的时候都是不加任何约束的,那样对性能的升高有多大,会不会潜移默化到数码的完整性。新手求大牛解答?

品种名称

属性值id

/**************2016年4月25日
更新********************************************/

1.善用explain,看看自己写的sql到底要涉及到多少表,多少行,使用了那多少个索引,根据那么些音信出色的开创索引;

类型id

特性值列

莫不本身叙述的不是很明亮,我想明白一下那上边改怎么规划,可能有情侣问我,为啥不依据分类吧数据库设计“死”呢,因为易于之后的壮大,我不能转手做的很完善,总是逐渐增加的,所以想那样做。

货物公共id

 

产品属性表:(product_id, property_id , property_name ,
property_value)

商品分类id

排序

衣物为例:

描述

attribute(商品属性表)

 

供销社自定义编号

goods(商品主表)

店铺id

店铺id

花色名称

例如:Array ( [206] => Array ( [name] => 款式 [3050] =>
毛衣 ) [207] => Array ( [name] => 材质 [3059] => 棉 ))

品牌称号

商品名称(+规格名称)

 

 

市场价

 

排序

 

是否开具增值税发票

产品属性含义元数据表

分类id

/*********************************************************/

货物上架时间

商品价位

规格3-制式,移动版,联通版,电信版

 

SPU = Standard Product Unit
(标准化产品单元),SPU是商品新闻聚合的矮小单位,是一组可复用、易检索的口径音信的联谊,该集合描述了一个产品的特征。通俗点讲,属性值、特性相同的货物就可以称呼一个SPU。例如,iphone4就是一个SPU,N97也是一个SPU,这一个与商家无关,与颜色、款式、套餐也非亲非故。

货物图片

goods_common(公共商品表)

原则4-合约,合约机,非合约机

深藏数据

类型id

 

店铺名称

属性值排序

spu,sku,item,规格,单规格商品,双准绳商品,三准绳商品…

数据库逻辑层
1)为数据库system表空间、user表空间、应用表空间分离
最起码user和运用不应当利用系统表空间
借使可能三类表空间应该分在分化物理存储上
2)应用表空间中
表的表空间、索引的表空间也应当分别
3)创制表时应该考虑表的特色
比如说有些表一大半时候是只插入记录很少修改删除
多少表是所有记录常常增、删、改
稍微表唯有个别字段
稍稍表有恢宏字段但一大半时候其中大多字段为空
多少表数据增进很快
稍微表数据常年基本不变
等等
不一样特色的表应该在开立时定义差别的开端空间和空间增进方案
以尽可能让一条记下处于一个老是的情理存储空间进步读取功用
除此以外要制订分歧的备份復苏和零散整理机制
4)索引不是更多越好
而是因表的特征而各异
数据变动频仍的表还应有树立目录定期重建机制
不然索引不但不会改良性能还会稳中有降性能
5)某些应用常用表比如lookup code之类的
借使可能尽量建在独立的表空间上
并把表空间建在飞快存储设备上

货物增短期

供销社名称         ————适度冗余,收缩关联表

相关文章