【www.shanpow.com--教学设计】
商品数据库篇(一):商城系统商品属性的数据库设计思路
商城系统商品属性的数据库设计思路
2012-04-05 15:14 by 少毅, 43 visits, 收藏, 编辑
最近看到一个题目，要求提出一套商品属性相关的数据库设计思路，要求是商品属性的类别（例如品牌，尺寸，颜色...）不确定，各个属性类别的属性值（例如品牌可能是HP,IBM...）不确定，同时需要实现针对不同属性类别的商品检索，例如检索出品牌为XX，尺寸为XX，颜色为XX的商品，各条件为AND操作，另外每个属性类别的条件可能为品牌=XX or 品牌 = YY这样的OR操作，最终实现出类似淘宝商品检索页面那样的功能如下(品牌，裤长等条件为AND关系，品牌中的可以选择多个品牌，为OR关系)
经过一番思考，数据库设计如下：
属性类别表spec
spec_id —— 属性类别id
spec_name —— 属性类别名称
属性值表spec_info
spec_info_id —— 属性值id
spec_id —— 属性类别
spec_info_name —— 属性值名称
商品表goods
goods_id —— 商品id
goods_name —— 商品名称
商品属性表goods_spec
goods_spec_id —— 商品属性id
goods_id —— 商品id
spec_info_id —— 商品属性值id
建立以上4个数据库后，spec表存放的是品牌，颜色，尺码等的属性名，spec_info表存放的是红色，蓝色，HP，IBM等的实际的属性值，再通过goods_spec表将一个商品跟它的属性进行关联，这样要实现类似淘宝的检索功能的SQL语句就可以编写如下：
假设要检索品牌为IBM或HP（在spec_info表中的spec_info_id 分别为1和2），颜色为红色（在spec_info表中的spec_info_id 为6），尺码为15寸（在spec_info表中的spec_info_id 为5）的商品
$sql = "select * from goods_spec where spec_info_id = 5 and goods_id in (select goods_id from goods_spec where spec_info_id = 6 and goods_id in (select goods_id from goods_spec where spec_info_id = 1 or spec_info_id = 2));
PS: 这些商品的搜索都是基于数据库 SQL 的， 可以看出用户选择了几个条件，最终的 SQL 就会有连几张数据库表的 SELECT 查询。 我已经用红色粗体标出 ！！
如果用户选中了 10 个条件， 那么一次搜索将会 10 次 select join （或者子查询） ！
商品数据库篇(二):数据库同步产品分类
目前数据库同步产品在行业的应用中越来越广泛，但是目前真正做到实时同步的产品并不多，放眼海内外，产品共有以下四种： 1、ORACLE自带的DATAGUARD： 2、ORACLE于09年收购的GOLDEN GATE： 3、QUEST 公司的SHAREPLEX: 4、WOXINTECH 公司的 PAC： 这四种产品各有各自的优缺点： 1、ORACLE DATAGUARD[/i]： 优点： 企业版本下自带 不用另外付费 逻辑模式可以实现实时同步 有逻辑和物理保护两种方式 能够进行主备库的切换 支持断点续传 缺点： 物理模式目的库不可用 逻辑模式不支持大对象、物理模式不够实时 源和目的不能是不同的操作系统和不同的版本 重新同步非常的复杂 对带宽要求较高，同时需要打开归档模式 需要DBA在生产库上操作， 风险很高 如果用户对备库的查询需要24小时使用,11G版本之前均无法满足 2、ORACLE GOLDEN GATE[i]： 优点： 目标端数据可用 源端系统和目标端系统异构 可选择复制内容 节约带宽 无中断初始化 保护时间在秒级 可以实现一对多、多对一 变化数据经过压缩，占用空间小 支持断点续传 缺点： 单独付费LICENSE 在主、备库均要安装程序，影响业务系统 需要开启归档模式 3、QUEST SHAREPLEX[/i]： 优点： 目标端数据可用 源端系统和目标端系统异构 可选择复制内容 节约带宽 无中断初始化 保护时间在秒级 缺点： 建表语句复制需要修改配置文件 不能支持事务的查看 无本地服务并且价格昂贵 维护工作量比DATAGUARD还大 4、WOXINTECH PAC[i]： 优点： 目标端数据可用 源端系统和目标端系统异构 节约带宽，带宽最小支持卫星56K 无中断初始化，业务系统无需停机 断点续传 单独服务器模式，不在主、备库安装任何程序 保护时间在秒级 支持事务的查看 安装简单，不影响主、备机软、硬件性能 支持大多数DDL和DML语句 支持大对象，支持OIT表 支持同步日志审计 缺点： 非国际品牌 目前不支持一对多和多对一 需要单独购买
商品数据库篇(三):电商商品数据库设计
作者：李平在电商系统中，商品模型至关重要，是整个电商的核心，下面通过一个简单的分析，设计一个基础的商品模型。 商品模型的演化 在以前，那时 CMS 很流行，最常见的模型是栏目 - 文章模型。于是做电商的时候，自然就继承了这种一对多的关系。只是栏目变成了分类，文章变成了商品。商品也具备了独特的业务属性。现在很多电商网站上左侧的菜单，也就是这个分类。后来我们慢慢发现一个问题，只有分类并不能适应所有的需求，比如 nike 鞋和 nikeT 恤，用户可能希望先看 nike 的所有商品，这个模型就不能满足。我们想在这个关系中，加入“品牌”概念。于是：这样基本用户可以在首页上通过分类或者品牌找到自己想要的商品，也可以直接查看热门的商品和新上架的商品。但是问题也来了，用户在进入分类后，展示在用户面前的是很多很多商品，用户希望再通过筛选查询出更接近他目标的商品。于是优秀的产品设计师，设计出了类似这样的 UI：用户可以通过这些筛选条件进一步缩小自己的目标范围，那么问题又来了，这样的产品需求排在程序员面前，怎么去实现它？经过分析，我们找出了一个方法，我们知道商品之间的属性可能存在着较大的差别，比如牛仔裤它有版型、腰型、裤长等属性；而电脑它有 CPU、显卡等属性，各类商品的属性是不同的。再进一步想，休闲裤也版型、腰型、裤长等属性；台式电脑或者笔记本电脑都有 CPU、显卡等属性。所以我们得出：一个分类对应若干属性，而一个属性，对应若干属性选项，而一个具体商品又对应若干属性选项（例如具体一条牛仔裤，他的裤长：7 分，裤型：直筒）。有点绕，仔细品味一下。从图上可以看出，分类和属性的关系（例如：“牛仔裤”分类下有裤型、裤长、版型等属性）、属性和属性选项的关系（例如：裤长属性有长款、九分裤、七分裤的选项）、商品和属性选项的关系（例如某条牛仔裤的裤长是 7 分裤）。至此，我们知道一个商品的分类、品牌以及它有什么属性和对应的属性值。那么通过筛选条件，自然就可以查询出指定的商品。这里特别说一句，价格也是属性，不要设想用商品表中的价格字段去做计算。这不利于查询也增加了复杂度，让商家编辑人员用属性来设置并保证他的正确性。 有了这个模型，我们大概就可以看到以下界面（请不要太关注左边，重点在右边和下面）： 这个页面展示商品的所有信息，按照之前的设计好像都可以满足。但是我们似乎感觉错过了什么，在图上右边我们发现该商品当前的颜色和尺寸，并且允许用户可以选择其他的颜色和尺寸。这给我们带来了疑惑，这里的“颜色”和“尺寸”是什么，一件商品的不同颜色不同尺寸是算一个商品还是多个商品。经过思考后，我们发现我们混淆了两个概念——“商品”和“货品”。不同规格的货品作为独立的商品。比如一条裤子的有 L 尺寸、M 尺寸、一个 U 盘有 16G 还是 32G 的，都是同样的货品，不同规格的商品。可以认为货品和商品是一对多的关系。弄清了这个概念，处理这个需求就容易多了，这里的“颜色”、“尺寸”我们就作为“规格”来处理，而红色、黑色；L 号、M 号我们视为规格的选项或者说规格值。一件货品对应若干规格，而具有某一规格值的货品就是商品。好了，现在好像差不多了。基于这个模型可以满足基本的商品搜索、展示的需求。搜索引擎也可以根据这个模型数据生成对应的商品索引，达到准确搜索的目的。商品模块还会和其他模块一起协作，比如用户系统、订单系统、支付系统等。一般情况下我们会把商品业务独立出来做成“商品中心”的服务，集中处理商品查询、更新、发布等业务，支撑其他业务。 从 SPU、SKU 开始 首先我们需要澄清上篇中的这两个概念，在上篇文章中“货品”是指一种概念物品，这种物品并不是一个具体的实物，当它具备具体的属性、价格时，才是一种实物，也就是商品。“商品”就是库存中一个具体的实物。例如：iphone6，就是一种货品，但用户购买的并不是货品而是商品，也就是用户最终购买的可能是：金色 -16G- 移动版 iphone6。换句话来说，货品是一种产品的称谓（如 iphone6），商品是用户购买的具体实物，具备特定的属性（如：金色 -16G- 移动版）。如果觉得这样理解还是比较混，那么忘记这两个概念，下面讲标准化的名称。 我们刚才说的 iphone6，书面称谓叫“SPU” Standard Product Unit （标准化产品单元），它是最接近用户认知的产品单元，比如用户说，我想买个 iphone4、iphone6、小米 4，这些都是 SPU，也就是用户普遍认知范围内的一种产品。然而在电商系统中只有 SPU 并没有什么卵用，用户购买时肯定要确定，需要什么颜色、多少 G 的，支持什么网络。所以，例如金色 -16G- 移动版 iphone6，就需要一个名称去规范它，这个名称叫“SKU” Stock Keeping Unit(库存单元)，换句话理解就是库存里面存的东西，库存里存在东西肯定是具体的某种规格的 iphone6。基于这个理解，我们先画下图：SPU,SKU 两个表，有各自的编码，这方便库存统计以及后台系统的管理，另外价格字段是在 SKU 中，这应该好理解，不同规格的 iphone6 肯定价格不一样，另外 SPU 与分类和品牌关联，如 iphone6 属于“手机”分类，“苹果”品牌。当然一个 SPU 也可能属于多个分类，可以做成多对多的关系。有了这个基础，我们再来看电商商品详情页是怎么设计的：我们看到这个页面其实是一个 SKU 的详情页，因为它指定了价格、颜色、版本、容量等信息，不同的颜色、版本、容量其实是不同的价格，不同的 SKU。我们如果要实现这个设计，我们需要加两个概念，就是“属性”和“属性选项”。“属性”正如这里的颜色、版本、容量。而“属性选项”则是金色、银色、移动 4G 版、16gb、64gb 等。可以看出“属性”和“属性选项”是一对多的关系，而“属性选项”和 SKU 则是多对多关系，一个金色 -16G- 移动版 iphone6，具备“金色”、“16G”，“移动版”多个选项，而一个“金色”选项除了对应 iphone6 还可以对于 iphone4。我们继续画图：需要注意的是，属性是对于一个分类的，这样设计的目的主要是为了属性能归类管理，也方便在添加产品时，通过分类对属性进行筛选。例如，“手机”分类有颜色、版本、容量等属性，而“衬衫”分类有“颜色”、“尺寸”。这里有博友可能有疑问，如果属性和分类是一对多的关系，那么属性表将会出现一些冗余，比如“手机”、“衬衫”都有颜色属性，但是在属性表中就会两条颜色的记录甚至更多。这里其实可以设计为多对多的关系。一对多的关系，可以在商品规模小、数据量不太大的电商上适应，这样的好处是，可以让产品发布者更好的管理属性选项和发布产品，因为即便是两个颜色的属性，但他们的属性选项确可以不同，对于“手机”来说，可能只有黑、白、金、银等颜色，但对于“衬衫”分类来说选项就可以有“红橙黄绿青蓝紫”甚至有“花格”。所以可以考虑牺牲冗余来提高商家发布者的体验。接下来我们来看另外一个特性——“规格”：“规格”代表这一个 SKU 具体的各项参数，是一个详细的产品规格说明，用户可以通过这些参数与其他同类手机做对比。这些参数中，部分参数将参与列表页的筛选条件中我们可以注意到两幅图，有些规格并不能对应上。这是因为我们在规格表中可以设置哪些规格显示在详细页中，哪些规格显示在列表筛选条件中。最终的商品模型就是这样：好了，这个电商商品模型的雏形就有了，但一个成熟的大型电商系统模型要比这个复杂的多，光是一个价格都会有一个单独的模块进行管理，比如市场价、进货价、成本价等，要进行成本核算，要与营销活动结合，双 11 折扣，或者与其他商品打包购买价格更便宜等。总之，需要根据业务的需要进行一步一步的扩展和设计。以后有机会介绍下电商中订单模型。
