购物网站数据库设计

要这样，这样你会有无数多的表，而且以后新的一个产品时候非常麻烦，如果要属于新的类别，而且还会因为避免数据库太复杂而使得许多不同类的产品归在一个类。而且你的程序很麻烦，要为每个类编写不同程序，因为数据表名不同。

应该用下面的办法，主要使用四个表存储所有类别的商品：

第一、类别名称表，字段有

类别ID，类别名称

1 电脑

2 洗衣机

第二、类别属性表，字段有：

类别ID，属性ID，属性名称

1 1 CPU

1 2 内存

1 3 屏幕尺寸

2 1 容量

2 2 类型

第三、商品名称表，字段有：

商品ID，类别ID

1 1

2 1

3 2

4 2

第四、商品属性表，字段有：

商品ID，属性ID，属性值

1 1 P4

1 2 128M

1 3 CRT 14

2 1 P4

2 2 512M

2 3 LCD19

3 1 9公斤

3 2 滚筒

4 1 8公斤

4 2 波轮

上面定义了四个商品，商品ID为1～4，分别是128M、512M内存的电脑，和9公斤滚筒、8公斤的波轮洗衣机。

这样定义的数据库结构，可以包含任何商品，一般不会改变，那么程序也就无需改变，定义新的产品、或者修改现有商品只需要在程序界面有 *** 作员点点鼠标。

这个问题的核心点在于：不同商品类别差异很大，如何设计通用的存储方案？简单来说，用数据库去存储所有信息，不管横表还是纵表，都有明显的缺陷：横表：同一个字段对不同商品含义不一样，这到了后面开发和维护是很蛋疼的纵表：一个商品的属性分布到很多行记录中，业务处理很麻烦，而且纵表的记录数会非常多，性能会有问题所以不要尝试只用数据库去统一解决这个问题，思路扩散一些其实就简单了：公共表：提炼商品公共的信息放到数据库，例如商品id、名称、发布的商家、发布日期、上架状态扩展表：将变化的信息放到另外一个表，可以是数据库表，例如电脑商品一个表、服装一个表；也可以将信息放到MongoDB或者ElasticSearch这类文档数据库。搜索组件：扩展表在全文搜索的时候不好实现，因此需要独立的组件负责搜索，可以用Elastic Search或者Solr来冗余一份数据，用于搜索。表结构不算复杂，因为项目关系只有SPU，没有涉及到SKU，但是可以做参考，更多的还是要根据项目实际情况设计。重点说明一下产品表的SPU，Keyword字段。本来之前设计了关系表，但是发现在做SQL查询时太痛苦，所以约定了一种数据存储结构（数据结构的重要性）基于上面的基础，可以实现URL规则变化的查询,类似京东的产品查询URL变化c=1,3 指分类层次关系ev=3_1+4_18 指SPU查询 按约定规则转换成字符串再进行查询。

---