还是表设计问题
一般的表设计的原则基本上都是:1.一对一关系加字段,一对多关系加表,多对多关系加关系表 
 当然了,对于一对多的关系可以变化一下成为一张表,比如加一个PARENTID字段作为主键的外键(能这样是因为他们的其他属性都相同),很多网站的分类都是这么设计表结构的。 
 那要是对于分类是多对多的关系呢?还这样设计成自联结模式吗?比如书的小分类的话,属于自然科学又属于社会科学(这个举例可能有点不适合但确实是存在这样的双亲或多亲的),那么是不是设计表结构的时候用多对多的关系表模式呢?那样的话对于分层就是有限层了。两个表的属性既然都相同,那有没有什么办法实现无限分层呢?   
------解决方案--------------------大类:tablea 
 ID name   
 小类:tableb 
 ID name   
 关联表:tablec 
 tableaID tablebID 
 这是我解决你上述问题的一般方法   
 那样的话对于分层就是有限层了。两个表的属性既然都相同,那有没有什么办法实现无限分层呢? 
 这和有限还是无限是没有关系的,你想无限加个parentID,一样的原理   
------解决方案--------------------LZ这就晕死了?呵呵   
 建议建一个代码表,就是所有的分类列表,然后一张分类关系表 
 1、create table type_list( 
 tl_id int identit(1,1) primary key, 
 tl_name varchar(100) 
 ) 
 --分类ID,和分类名 
 2、create table type_relation( 
 tr_id int identity(1,1) primary key, 
 tr_parent int, 
 tr_child int 
 )   
 我这只是就逻辑上简单说而已,如果具体查询需求有特殊情况,可能会不一样。 
 但是一般情况这个就足够了 
------解决方案--------------------多对多的关系是使用主从表关联的啊.这个似乎和有限分层无限分层关系不大吧?楼上的例子很典型啊,你要再分类就再加表么
------解决方案--------------------哦,你也可以采用字段驱动的方式,把字段名和对应关系都作为数据写到一个关系设置表里.这样,可以无限的加入字段,架构也很灵活!很多软件现在都采用这个方式了.允许用户自己增加字段和表结构,自己改查询等
------解决方案--------------------ID name parentid   
 做棵树吧,你的问题都能解决