商品属性类别表
商品属性表
现在问题是，想给商品的这些类别进行归大类，如零食，饮料，酒水，归为为食品干货类
是不是在这两个表里设计不怎么合适？
若果按老办法，大类，中类，小类都设计一个表，商品表里就不是有很多ID字段了？是不是也不太合适？还是只能这样？
应该怎么设计？
麻烦各位帮忙看看，谢谢各位了
9 个解决方案
#1
按你老是的做法吧
你商品表中可以只存储一个“小类”的ID啊
然后根据根据小类的ID找到中类的ID，根据中类的ID可以找到大类的ID，这样一步一步地网上去找（多表关联去取数据）
你现在应该打好基础
刚开始的话就应该按照这中数据库设计范式（三范式或者BC范式）的思想去设计表
（置于大数量设计表的时候，有一种”反范式“的做法，那是以存储冗余数据去换查询性能的问题，目前你先不用考虑了吧）
你商品表中可以只存储一个“小类”的ID啊
然后根据根据小类的ID找到中类的ID，根据中类的ID可以找到大类的ID，这样一步一步地网上去找（多表关联去取数据）
你现在应该打好基础
刚开始的话就应该按照这中数据库设计范式（三范式或者BC范式）的思想去设计表
（置于大数量设计表的时候，有一种”反范式“的做法，那是以存储冗余数据去换查询性能的问题，目前你先不用考虑了吧）
#2
你说的“反范式”是不是那种只用一张表，可以不断增加上级类别？
一张表这样的设计，查询一个“食品”下的“饮料”的“可口可乐”，汗，这种查询语句要怎么写？
#3
该回复于2012-10-21 15:05:05被版主删除
#4
商品信息中既存储一个你这个里的“小类”ID，再存储一个“中类”ID，再存储一个“大类”ID
本来可以通过一个“小类”ID找到“中类”ID的，也就是“可口可乐”的类别是饮料，饮料的类别是食品
按理来讲，这里就不需要把食品信息存储在可口可乐中，食品信息是冗余字段，但是为了在查询时候减少一次（由饮料找食品）的关联操作，就多存储一个食品信息在可口可乐信息中，就类似于这样。
（置于大数量设计表的时候，有一种”反范式“的做法，那是以存储冗余数据去换查询性能的问题，目前你先不用考虑了吧）
我说这句话就是为了防止有人说我纯理论话，太学院派，其实这个是一种在特定情况下，为了效率，与教科书上讲的有冲突的做法，但很不幸，似乎误导了你，呵呵。
从你的问题来看，貌似你没有弄懂我的意思
建议你回头看看三范式是怎么回事，《数据库系统概论》里面讲的非常清楚，你们应该学这本书的。
#5
可以这样设计：
商品分类编码 商品分类名称 是否末级
01 食品干货类 0
0101 零食 1
0102 饮料 1
0103 酒水 1
02 其他类 0
0201 ... 1
另外：楼主的商品名好像太长了吧
商品分类编码 商品分类名称 是否末级
01 食品干货类 0
0101 零食 1
0102 饮料 1
0103 酒水 1
02 其他类 0
0201 ... 1
另外：楼主的商品名好像太长了吧
#6
嗯，知道了，谢谢
#7
哦，这样..
名字我会改了，主要英文不好，谢啦
#8
对了，这样分类编码，是不是不能设置自增了？如果用户要在食品干货插入一个小类，要怎么生成分类编码？
#9
有一种叫物料清单（Bill of Material, BOM）结构，其实可以考虑一下使用，具体你到网上找找会更清晰，FAQ贴那里也有具体的实现。
另外一种方式，是以前我公司的做法，当时做服装类的网站。也会有很多分类，是用XML树形结构来实现这种关系的存储。
这些是思路，但是具体实现，还是要找相关详细资料好。
另外一种方式，是以前我公司的做法，当时做服装类的网站。也会有很多分类，是用XML树形结构来实现这种关系的存储。
这些是思路，但是具体实现，还是要找相关详细资料好。
#1
按你老是的做法吧
你商品表中可以只存储一个“小类”的ID啊
然后根据根据小类的ID找到中类的ID，根据中类的ID可以找到大类的ID，这样一步一步地网上去找（多表关联去取数据）
你现在应该打好基础
刚开始的话就应该按照这中数据库设计范式（三范式或者BC范式）的思想去设计表
（置于大数量设计表的时候，有一种”反范式“的做法，那是以存储冗余数据去换查询性能的问题，目前你先不用考虑了吧）
你商品表中可以只存储一个“小类”的ID啊
然后根据根据小类的ID找到中类的ID，根据中类的ID可以找到大类的ID，这样一步一步地网上去找（多表关联去取数据）
你现在应该打好基础
刚开始的话就应该按照这中数据库设计范式（三范式或者BC范式）的思想去设计表
（置于大数量设计表的时候，有一种”反范式“的做法，那是以存储冗余数据去换查询性能的问题，目前你先不用考虑了吧）
#2
你说的“反范式”是不是那种只用一张表，可以不断增加上级类别？
一张表这样的设计，查询一个“食品”下的“饮料”的“可口可乐”，汗，这种查询语句要怎么写？
#3
该回复于2012-10-21 15:05:05被版主删除
#4
商品信息中既存储一个你这个里的“小类”ID，再存储一个“中类”ID，再存储一个“大类”ID
本来可以通过一个“小类”ID找到“中类”ID的，也就是“可口可乐”的类别是饮料，饮料的类别是食品
按理来讲，这里就不需要把食品信息存储在可口可乐中，食品信息是冗余字段，但是为了在查询时候减少一次（由饮料找食品）的关联操作，就多存储一个食品信息在可口可乐信息中，就类似于这样。
（置于大数量设计表的时候，有一种”反范式“的做法，那是以存储冗余数据去换查询性能的问题，目前你先不用考虑了吧）
我说这句话就是为了防止有人说我纯理论话，太学院派，其实这个是一种在特定情况下，为了效率，与教科书上讲的有冲突的做法，但很不幸，似乎误导了你，呵呵。
从你的问题来看，貌似你没有弄懂我的意思
建议你回头看看三范式是怎么回事，《数据库系统概论》里面讲的非常清楚，你们应该学这本书的。
#5
可以这样设计：
商品分类编码 商品分类名称 是否末级
01 食品干货类 0
0101 零食 1
0102 饮料 1
0103 酒水 1
02 其他类 0
0201 ... 1
另外：楼主的商品名好像太长了吧
商品分类编码 商品分类名称 是否末级
01 食品干货类 0
0101 零食 1
0102 饮料 1
0103 酒水 1
02 其他类 0
0201 ... 1
另外：楼主的商品名好像太长了吧
#6
嗯，知道了，谢谢
#7
哦，这样..
名字我会改了，主要英文不好，谢啦
#8
对了，这样分类编码，是不是不能设置自增了？如果用户要在食品干货插入一个小类，要怎么生成分类编码？
#9
有一种叫物料清单（Bill of Material, BOM）结构，其实可以考虑一下使用，具体你到网上找找会更清晰，FAQ贴那里也有具体的实现。
另外一种方式，是以前我公司的做法，当时做服装类的网站。也会有很多分类，是用XML树形结构来实现这种关系的存储。
这些是思路，但是具体实现，还是要找相关详细资料好。
另外一种方式，是以前我公司的做法，当时做服装类的网站。也会有很多分类，是用XML树形结构来实现这种关系的存储。
这些是思路，但是具体实现，还是要找相关详细资料好。