新人求教，购物网站商品分类的数据库是怎么设计的？_java吧_百度贴吧
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&签到排名：今日本吧第个签到，本吧因你更精彩，明天继续来努力！
本吧签到人数：0成为超级会员，使用一键签到本月漏签0次！成为超级会员，赠送8张补签卡连续签到：天&&累计签到：天超级会员单次开通12个月以上，赠送连续签到卡3张
关注：578,567贴子：
新人求教，购物网站商品分类的数据库是怎么设计的？收藏
是要一个大分类，一个小分类，还是就一个category分类就行了？
java培训---美国上市公司出品,入学签订就业协议,名企疯抢达内学员.java,O基础小班授课,java专家领衔授课,免费试听,满意后付款!
根据用户需求来做数据字典，如果是购物网站的话那么数据字典要求就多了，因为后台管理时和前台显示需要关联，如果只是分类可以用代号查询，例如书籍为1，衣服为2，可以在表中设置用查询语句查出来就好了
登录百度帐号推荐应用
为兴趣而生，贴吧更懂你。或声明：之所以定位在"中小型"商城系统，而非&大型&(指淘宝、拍拍这类巨无霸)，理由很简单----我一直都呆在(创业型的)小公司，没见过这些大家伙是怎么设计的:)
之前发表过一篇""，部分童鞋对于后台数据库的设计比较感兴趣，于是今天把这部分也补上。
一、产品分类设计越来越多的商城系统都热衷于选择&无限级分类&的设计，我也不例外，因为它方便扩展。这部分就不详细展开了，详见
稍微啰唆几句：1.1 我习惯于把所有表加上前缀T_(即Table的第一个字母)，把所有字段加上前缀F_（即Field的第一个字母），把视图加上前缀V_(即View的第一个字母)...，这样最大的好处是在写linq to Sql时，智能提示(感应)会很爽，所有相关的东西全部列在一起，省去记忆脑细胞无数
1.2 这是我06年时从动网论坛剥下来的表结构(当然我又做了一些改造)，它的最大特点在于：通过添加一些辅助字段完全避开了无限分类中的递归问题。1.3 之所以用guid做为主键，主要是考虑到数据库迁移时的方便，当然guid主键会带来一些性能上的损失（二害相权，取其轻也），为了改进可将guid改为comb主键(详见 &&)1.4 考虑到很多人为了各种原因喜欢把分类页生成静态页，而为了url地址的简短/友好，guid主键有些长，所以我又添加了一个辅助字段F_AutoId，这样生成的静态页可以从类似"43AA--6E6B6B76FC6E.html"变成"1234.html"
二、产品分类--产品关联设计
如果&产品:分类&是1:1关系(即：一个产品只能归到一个分类下），则直接在产品表(T_Product)中增加一个字段(F_ClsId)即可。如果&产品:分类&是1:N关系(即：一个产品能同时归到多个分类下)，则必须新建一个表（T_ProductInClass），建二个字段(F_ClsId,F_ProductId)，并把这二个字段设置为联合主键即可。
注：1:1还是1:N取决于需求，没有谁好谁坏之说。
三、扩展属性终于到了正题了，对于产品的扩展属性，因为(在产品分类未选择之前)无法事先确定产品的扩展属性有哪些，所以这部分属性显然不适合通过在T_Product中预留一大堆字段来解决(而且这样性能也不好)
考虑到扩展属性总是基于分类的(比如：电脑类的产品应该具有"CPU频率、内存容量、显示器尺寸、硬盘大小"等扩展属性，而服装类产品应该具有&颜色、尺码、品牌、面料&等扩展属性)，所以可以新建一个"分类扩展表"用于存储分类的扩展属性基础定义。
CREATE TABLE [dbo].[T_ClassAppend](
[F_Id] [uniqueidentifier] NOT NULL,--主键
[F_ClsId] [uniqueidentifier] NOT NULL,--关联外键(分类ID)
[F_DisplayName] [nvarchar](50) NOT NULL,--(扩展属性)显示名称(比如：品牌，内存大小，颜色之类)
[F_FieldName] [nvarchar](50) NOT NULL,--(扩展属性)字段名称(比如：Brand,Memoery,Color之类)
[F_ValueType] [nvarchar](50) NOT NULL,--字段类型(比如：字符串，整数，日期之类)
[F_ValueLength] [int] NOT NULL,--属性值长度(比如:50)
[F_InputType] [nvarchar](50) NOT NULL,--输入类型(比如：文本框，文本域，下拉框，复选框之类)
[F_DefaultValue] [nvarchar](500) NOT NULL,--默认值
[F_IsRequired] [tinyint] NOT NULL,--是否必须填写
[F_isShow] [tinyint] NOT NULL,--显否显示
[F_Orders] [int] NOT NULL,--排序号
[F_AutoId] [int] IDENTITY(1,1) NOT NULL,--辅助自动ID(预留)
CONSTRAINT [PK_T_ClassAppend] PRIMARY KEY CLUSTERED
[F_Id] ASC
)WITH (PAD_INDEX
= OFF, STATISTICS_NORECOMPUTE
= OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS
= ON, ALLOW_PAGE_LOCKS
= ON) ON [PRIMARY]
) ON [PRIMARY]
保存数据后的大概样子如下:
解决了扩展属性的定义问题，接下来再来考虑产品的这些属性到底应该保存在哪里？
先回顾一下产品上传的基本逻辑，在不考虑扩展属性的传统场景下：用户进入产品发布页面，选择产品分类，然后填写其它产品属性，最终保存到数据库。
分析一下：只要用户选择了分类，我们就能得到分类ID，进而得到该类的&扩展属性定义&，也就知道了该产品应该具有哪些扩展属性，如果这时有一张特定的产品扩展属性表（来对应这些扩展属性的定义），那么直接把这些扩展属性insert进这张表即可。
技术处理：保存产品时，先得到用户选择的分类ID，然后根据上面定义的T_ClassAppend分类扩展属性定义表，去检查是否已经生成了该类的"产品扩展属性表"，如果没有则动态生成一个类似T_Product_XXXX的表(注:XXXX即为分类的F_AutoId值)，然后该干嘛干嘛，常规公共属性保存进T_Product，扩展属性保存进T_Product_XXXX。
注：T_Product 与 T_Product_XXXX 之间应该有(产品ID的)主外键关联
注：图中的F_ID其实可去掉，没啥实际意义（最初我是打算用来保存记录流水号的，后来发现完全没啥必要，这一点精减工作就留给大家去做吧）
可能存在的问题:1、产品修改时，如果从分类A改成了分类B(即发布时，产品分类选错了，在编辑时，重新指定产品分类)，那么扩展属性对应的保存表名，可能会从T_Product_123 变成 T_Product_456，这时要注意先把原来的T_Product_123中的记录删除，不然时间长了，会留下一堆冗余记录。
2、分类扩展属性有变动时，比如电脑类，又新增了一项属性："是否支持双显卡(F_IsDoubleVGA)"，那么这里原来的产品扩展属性表T_Product_123，也要相应的增加一个类似F_IsDoubleVGA的字段类型
四、搜索问题的解决
这部分其实是最难解决的，不过也不是没有办法，分二种情况：
1、第一种情况
通常情况下，用户其实很少一上来就搜索扩展属性，很多场合下，用户会先浏览某感兴趣分类列表，然后再挑选商品。
这种情况就好办多了，因为用户一旦确定了分类，也就意味着能得到分类ID，进而得到最终的产品扩展属性表名(比如T_Product_123)，这时搜索就简化为搜索 T_Product 与 某一个特定的T_Product_XXX
2、第二种情况
如果系统要求用户直接在搜索栏里输入 "ThinkPad 双显卡 4G内存 T系列"这类关键词，然后自动匹配出所有属性/扩展属性的商品。
那么，其实这已经演化成网站搜索引擎的需求，传统的 select... like ...在这种需求下基本上已经没啥用处了，可以考虑用lucene或园子里"盘古分词"作者 (注：该兄是搜索引擎方面的资深人士，值得信赖！)的解决方案来实现站内搜索引擎。
后记：早上写得匆忙，有些细节没写详细，现在补上。
看到回复中有些朋友觉得这种设计表太多，太复杂，这个嘛...其实我觉得还好啦，只是在原来的分类表T_Class的基础上，增加了一个T_ClassAppend表而已，至于那一堆的T_Product_XXX 表，我写了一个分类管理器来自动生成，不用手动来做，另外再封装一些逻辑（比如根据分类ID自动返回扩展属性表名之类），对于普通开发人员来讲，开发难度只是轻微增加而已.
上图为分类管理器的界面。
继续更新：
看到越来越多的人回复来讨论这个问题，很是高兴（相互交流才能进步），特地又加了一张图，建议大家先在完全明白我的意图之后，再讨论如何改进，不然大家你用你的说法，我用我的说法，但其实完全有可能只是同一个问题的不同说法，这样沟通起来比较费劲。
其实我的想法很简单:
将商品的共用属性(比如：价格，商品名称，商品编码这些肯定要有的东西)与扩展属性(即：根据分类不同而不同的非共用属性，比如电脑类的"CPU/硬盘容量..."，充值卡类的"面值/适用地区..."，服装类的"尺码/颜色...")分开保存而已，相当于原本应该保存一张表T_Product中的东西，拆分成二部分。（但由于每个分类的特性不同，每个类对应的产品都有不同的扩展属性值，所以不适合把所有产品的扩展属性保存在同一张表中，如果这样可以的话，干嘛还要费心把共用属性与扩展属性分开，搞拆分这么麻烦?）
共用属性保存到 T_Product表，而扩展属性保存到 T_Product_N 表（其中N 与 某一个分类记录的ID对应）
在逻辑上可以认为，每条产品记录的全部属性，都是 "T_Product中的一条记录" + "T_Product_N（N为该产品所属分类的对应Id）中的一条记录" 共同描述的
至于表的个数，其实只增加了& 1 + N & 张表（1即多出来的分类扩展属性定义表，而N即为T_Class中产品分类的记录条数），所以只要分类数不变，产品扩展表的数量也是一定的。
至于大家提到的品牌问题，品牌其实最适合与分类当作平行处理，毕竟很多时候搞活动做专题，都是以品牌作为主要选择依据的（如果当成扩展属性处理，并非行不通，只是不适合）
另外之所以会引出搜索问题，其实反过来考虑很容易理解，如果不做拆分，按传统方式，用Sql语句直接搜索T_Product表即可。但现在把属性分成了二部分，所以很难确定用户搜索时，是想搜索共用属性，还是扩展属性？所以有上面提到搜索的二种情况。
最后谈一下数据库查询的问题，看到'小菁菁'同学的观点:数据库就是为了查询方便。基本上，这个没错！但是如果您遇到过单表千万级数量的情况，而且基于某些要求又无法利用索引。(比如最纠结的like该不该用的老问题：如果不用like，强制用=来处理，当然速度会快很多，但是查询就不准确，比如用户就记得产品描述中的几个字，别的都不记得，这时候站在用户的立场，无疑模糊查询是最好的，但是在海量数据情况下，这样做又几乎是灾难)。在这些特定情况下，关系型数据库(不管是sqlserver还是oracle)的查询能力都是无能为力的，如果您去百度一下关于搜索引擎的数据库设计，几乎看不到采用关系型数据库做为查询核心的。推荐几篇我以前收集的搜索引擎架构文章给您参考下
当然"学无先后，达者为先"。如果大家有更好的解决方案，欢迎回贴指导。
最后YY一句，就这种拍脑袋的设计，07年时曾经受住了日均IP10万的访问量，当时日均IP从中国站长站监测的结果，已经达到了同期中国新蛋日均IP的1.5倍(当然还有其它优化措施，这个就不一一展开了)，不过很可惜的是，后来公司经营不善，烧钱太快，很快阳痿了，我也就没有机会经历更大的挑战。
阅读(...) 评论()以下试题来自：
单项选择题设某系统中有商品销售表（商品号，商品类别，数量，单价，销售日期，销售时间），该表数据量大，在I作时间会被频繁插入销售数据。用户需要经常查询每天各类别商品的销售总量。为了提高查询效率，下列措施中最为有效且合理的是（）
A．在商品销售表上针对商品类别和销售日期属性建立索引
B．建立商品分类别日销售汇总表（商品类别，销售总量，日期），每产生一条新销售记录时实时更新该表，用户直接使用该表进行查询即可
C．在商品销售表的商品号和销售日期属性上建立索引
D．建立商品日销售汇总表（商品号，商品类别，销售总量，日期），每产生一条新销售记录时实时更新该表，用户直接使用该表进行查询即可
为您推荐的考试题库
你可能感兴趣的试题
A．完全转储
B．增量转储
C．差量转储
D．增量加差量转储
A．执行Adodc 1.Delete方法
B．执行Adodc l .ReCOrdset.Delete方法
C．先执行Adodcl.Delete方法，然后再执行Adodcl.Update方法
D．先执行Adodc l .Recordset.Delete方法，然后再执行Adodc 1.Recordset.Update方法
A．仅I、11和III
B．仅II、N和V
C．仅I、11、III和V
D．全部都是
A．该角色是SQL Server系统提供的服务器级角色
B．该角色是SQL Server系统提供的数据库级角色
C．该角色是系统管理员定义的服务器级角色
D．该角色是系统管理员定义的数据库级角色
A．使查询执行时I/O代价最省
B．使查询执行时CPU代价最省
C．使查询执行时通信代价最省
D．使查询执行时I/O代价和CPU代价之和最省
热门相关试卷
最新相关试卷在tp框架中怎么从数据库中遍历商品类型-中国学网-中国IT综合门户网站
> 信息中心 >
在tp框架中怎么从数据库中遍历商品类型
来源：互联网 发表时间： 16:02:55 责任编辑：鲁晓倩字体：
为了帮助网友解决“在tp框架中怎么从数据库中遍历商品类型”相关的问题，中国学网通过互联网对“在tp框架中怎么从数据库中遍历商品类型”相关的解决方案进行了整理,用户详细问题包括:RT,我想知道:在tp框架中怎么从数据库中遍历商品类型，具体解决方案如下：解决方案1：遍历商品类型‘是指什么？找出商品表中所有的商品类型？
3个回答1个回答1个回答5个回答3个回答1个回答1个回答3个回答3个回答2个回答1个回答1个回答1个回答1个回答1个回答1个回答1个回答1个回答1个回答
相关文章：
最新添加资讯
24小时热门资讯
Copyright © 2004- All Rights Reserved. 中国学网 版权所有
京ICP备号-1 京公网安备02号