求太平洋产品库的设计思路~

这样的数据库其实也只是复杂，除了本身复杂外对硬件还有要求.
一个存储大类的表,一个二级分类的表,剩下的就只是一个产品表,为了完成能从后台操作添加各级分类与产品参数的目的,产品表只能有一个,无论是大类还是二级分类都能存储在一起,那样的话方便的是按产品参数查找产品,由于想搜索出与关键字有关的所有记录,也能这样.
这样做的好处是能从后台对各种数据的管理,也是一种一劳永逸的方法，后果是庞杂的产品信息都会堆积在一个表里，SQL查询时费时和对服务器本身要求提高了，再就是这么一个庞杂的产品库最少是要用SQL SERVER来做到，由于运用这个放大，表的数量会减少，人工管理就方便了，我觉得合理得去消耗服务器的资源是可以行得通的。

方法很多啊.
我提供一种比较简单的方式.
id int 标识
parent_id int 上级类型的ID
title nvarchar 类型名称,比如笔记本
note nvarchar 注释信息.
''
type_table nvarchar 类型表
这个可以形成一个无限止的目录树结构.

至于不同产生的参数问题,那解决的方案也很多
比如在上表中建议一字段type_table,用来存放不同类型产品的表名
而在相应的表中设定本类产品的参数字段.

当然这只是其中的一种,思路很多,设计方式也很多.你自己多动脑吧.

数据库大了,太复杂了.象这样的大型数据库设计的好坏和系统的效率有很大的关系的,这样的大工程估计要数据库设计师这样的人专门做吧!

1.产品大类表

id 大类名
1 书籍
2 陶瓷

2.产品小类表

id 分类名称 关联大类id
1 小说 1
2 教材 1
这个应该好理解，小说 和 教材 都从属 书籍类 （当然你也可以写一个表里 大类表 多一个字段 大类为0 其他分类该字段为大类的id）

3.参数