关键词的表设计.高手请进~.词量会上千万条记录.
现有产品已经接近到300万条记录.并且每月以1万到5万左右速度增长.
这个问题已有办法解决,每100万条记录用1张表.100到200万用第二张表,根据客户需要的ID,再调相应的表.MSSQL在双核CPU+高内存上调用200万到300万条记录的表很轻松.

以上是废话.

现在准备给这300万条记录加入文字描述功能,词汇添加.而词汇是大众都可能随时添加的.
开始的想法是每添加一个词就增加一条记录.后来细想,不对.300万件产品按照每件产品平均20个关键词(即20条记录),如此一来将达到300*20=6000万条记录.数据库根本就承受不了.

现在已想到基本的解决方案如下,望高手指点:

id       pid       keytxt   addtime
设计4个字段,ID为自动增长的,PID为产品ID(数字),ADDTIME为日期.
KEYTXT为关键词字段,用varchar类型,长度为120(即60个汉字,30个词,扣除空格或隔离符号后,可以存20个词左右).

添加词汇的时候,用空格隔开,然后直接插入KEYTXT
如:女人   天空   海   马
词汇添加时,先对每一个词进行一次like查询,如果不存在这个词,可视为添加,如果存在则不再需要添加.
再判断一次是否达到120的字节,如果达到,则分次进行添加.

如此一来,平均每件产品才会添加300万*3=900万记录左右.比原来的6000W小很多了.

因为未经测试,所以另外想咨询一下各位SQL高手:
1.这样的设计模式,是否合理?有没有更好的办法?
2.查询的时候,用的是like进行查询,在数据库达到几百万条后,会不会出现严重的延时?
3....其它注意事项.

------解决方案--------------------
1 不合理,可以说,你现在把关键字合并把记录条数压缩到900万以内.比原来的6000W条数据的速度可能还要慢.因为
2 查询的时候,用的是like进行查询,在数据库达到几百万条后,会出现严重的延时


------解决方案--------------------
6000万的数据也肯定比你这个快。

做数据库查询的话 肯定是要建一张关键词表的。查询不能在主表中Like，那死定了
------解决方案--------------------
不用试了，你的方法肯定不如分开处理好！
修改方案吧！