还是表设计问题
一般的表设计的原则基本上都是：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
做棵树吧，你的问题都能解决
