本文主要是介绍数据库设计（物品属性需要差异化），希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
举个例子
商品有很多种，但是每种商品的属性不同（白酒有度数，汽车没有度数），这时靠单独的商品表可能并不好处理，当然靠加字段也能实现但是类型肯定有很多冗余，或许对应类型有限的系统还能应付，但是如果有几百种不同商品，全部加上可能上万的属性这样靠单表就不现实了。
想法
先定义类型，然后定义类型的属性，在添加商品，最后按照定义的属性给商品设值。基本结构如下：
测试
添加两个商品及数据，这里加两个白酒及相关属性和属性值
g_goods_type
g_goods_property
g_goods
g_goods_property_value
查询结果
SELECT gg.`id`,MAX(CASE ggp.`name` WHEN '名称' THEN ggpv.`value` ELSE NULL END) '名称',MAX(CASE ggp.`name` WHEN '容量' THEN ggpv.`value` ELSE NULL END) '容量',MAX(CASE ggp.`name` WHEN '度数' THEN ggpv.`value` ELSE NULL END) '度数',MAX(CASE ggp.`name` WHEN '厂商' THEN ggpv.`value` ELSE NULL END) '厂商'
FROM `g_goods` gg
LEFT JOIN `g_goods_property_value` ggpv ON gg.`id`=ggpv.`goods_id`
LEFT JOIN `g_goods_property` ggp ON ggpv.`goods_property_id`=ggp.`id`
GROUP BY gg.`id`;
小结
这种表设计不是说就这几个表就可以解决所有问题，具体情况具体分析，比如这种结构查询就不好查，如果扫描数据太多会导致查询慢。这时可能需要借助es之类的系统。
同时传统结构模型属性和数据库字段是对应的，但是这种方式模型和数据库无法写死对应关系，那么可能需要动态的处理查询结果等数据等等，总之就是需要建立一套规则来处理业务。
这里只是提供一个想法，具体使用结合项目，尤其是类型数量可预知的系统没有必要使用这种方式，使用这种方式会增加项目的复杂程度，投入产出比不高。
这篇关于数据库设计（物品属性需要差异化）的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
