关于标签的的效率和准确性研究
Written by angel on 2006, March 30, 4:33 AM. 技术相关
我的标签表结构设计还有查询。的确是存在一些问题。当初我敢说。TAG的想法刚被流传的时候。我就开始注意到这个功能了。所以在国内主流的PHP开发的BLOG程序中,是第一个支持此功能的。以前有人和我说过。现在又有高手提起。我的标签的确存在着两个问题。感谢yake.chen@dudu-inc.com。
Tag功能的表结构设计存在一定问题。目前是通过模糊搜索查询方式来匹配标签,进而通过标签来匹配到文章。这个实现方式有两个致命的缺点:
- 大数据量下标签搜索的效率问题。
- 标签匹配的准确性问题。(所记录的标签出现条数并非模糊搜索显示出的条数)
的确。本来刚有人和我提出的时候,我就把改善TAG表列入计划中。可是后来忘记了。结果这次发布的测试版后。高手又提出了这个问题。才让我想起来。的确要改善。
|
因为标签是个 多对多的结构体系 一篇文章可以有多个标签,一个标签可以对应多篇文章。所以一般性的解决办法是为标签结构使用两个表来描述。
你现在的标签表算一个,另外一个记录标签和文章标签的关系。
比如建立一个表tag_relation 三个字段 tid, article_id, tagid每插入数据库一个标签的时候同时更新这两个表。tag_replation的tagid字段对应你的tags表的tagid,tag_relation 表的tid是个自增的主键记录每次入库的tag。article_id是此tag对应的文章id,这个表记录的基本只是数字型的ID值所以存储空间消耗不大且实现了高效精确匹配的问题。
|
我自己也想了想关于标签的表结构的问题。如果不用另外一个表记录关联字段,而是用tag表的一个字段来保存一个关联ID,也是一个比较好的办法吧??比如:
| Field |
tagid |
tag |
usetime |
aids |
| Value |
1 |
angel |
5 |
1,3,4,8,5 |
这样的话,我必定要先从URL获取name,也就是:
http://www.4ngel.net/blog/angel/?action=tag&item=angel
select aids from tags where tag='angel' 1 query
然后再来
select * from articles where articleid in (aids) 2 queries
这样效率问题也解决了。准确性也解决了。不知道大家还有没有其他的看法。如果使用另外一个表来放关联字段。那不是还要来一次LEFT JOIN?
希望各位多多交流技术。
上一篇:
SaBlog-X进入测试阶段
下一篇:
提供FCKeditor、TinyMCE、eWebEditor精简版
相关文章
访客评论
引用 劲草 说过的话:
这个软件的后台登陆怎么在首页上没有显示出来啊! 我每次登陆我的博客发表日志 都得从地址栏里输入.../blog/admin/admincp.php 才能进入我的后台,好麻烦的!不知道各位是不是也和我一样这么做呢? 有没有简单的办法? 请指教!谢了!
一樣的
有个问题想请教:
我始终不会用in,总是查不出来数据,手册也讲得不是很清楚
X1.0中TAGS限制15字节是不是有点少?
有些关键词大意都写不全。
当一篇文章有多个tag的时候删除文章时是不是比较麻烦呢?
Field tagid tag usetime aids
Value 1 angel 5 1,3,4,8,5
仅效率而论,当一片文章有10个或者更多的tag时删除一片文章的时候是不是很麻烦呢。我的想法是这样,当删除一个标签时就要删除aids里面的文章id,同时次数减一。我觉得麻烦的在于aids里。是不是要吧aid里面的id查询出来(1次查询),然后explode,然后去除aid再合并update(2次)这样如果有10个标签删除篇文章就要查询数据库20次;而且当tag更新的时候怎么做?假如我现在要把其中的一个“标签”改为“tag”,那么我就要现在原先的标签中减一,去除标签update(还是2次查询)然后插入新的。不知道有没有别的方法或者说我的理解是不是正确的,之前我做关键词索引的时候就是因为这个放弃了单表。
很感谢有技术性的讨论。其实这样的设计。在后台管理tag的时候,的确是有点低了,查询也是很多。不过这个换来的是前台高效率。所以我选择牺牲后台效率,毕竟后台不是经常用的,而前台却会经常用到tag。这样其实算起来,按照使用频率,还是这样划算点吧?而且我按照最先使用tag的网站(似乎是blogbus)来设置,每篇文章5个以内的标签。
欢迎继续讨论。
没想到你也还在啊,我天天通宵(跑题了,呵呵)
不知道我上面的思路对不对……
我开发的是cms系统,原本是想对整个文章作索引,所以一篇文章的关键词将非常多。在这种情况下用你上面单表似乎并不合适。因为如果做全文索引那么关键词可能比文章还多。但是tag如果不多你的方法还是不错了。在gg的黑板报看过一篇关于搜索引擎的文章,说是在关键词后面跟着一堆长长的索引表,不过人家是用二进制的。只是不知道如何计算
见天豁然开朗,原先思路一直封闭在单表了,找baidu、gg和yahoo都没能给我答案,后在在phpx搜索帖子来到这的,所获不小,现在决定有多表了。你的日志搜索用的是标签搜索还是用like?
CMS和BLOG有所不同,估计你不仅仅在文章里使用tag吧?虽然说我这样没有发现匹配的错误。不过心里作用感觉还是id=id配对比较准确一点。这东西真的每种方法都有利弊。看场合吧。
日志搜索是关键字搜索吧,肯定还是用like了。不过like速度很慢而且消耗较多资源,所以要把搜索结果写到表里从新查询。这样如果翻页的话,不至于对服务器造成太大负担。
我用标题切词作为文章的tag,同时也可以作为搜索用。因为按一般来说标题既是文章的概括,特别是新闻类的文章更明显。所以这类的文章直接拿标题分词是不错的,标题分词后可以作为文章的keywords,如果keywords想要多点还可以同时联合description一起切词。当然,description也可以自动从文章的内容提取。
原先一直用文本存储,刚接触sql不久对sql的操作还不很熟悉。我也经常看到说存储搜索结果,不过就是不明白什么原理。我不明白的地方是存储的搜索结果什么时候删除掉,否则搜索的次数多了那么垃圾将非常的多,希望能指教!
这是表
keywords | tatols | ids
asdasd | 5 | 1,2,3,4,5
上面是个简单的例子,具体还是可以看看SABLOG-X。因为你搜索的时候使用like,假设结果非常多,或者要用到翻页。这样就形成多次like,对效率有很大影响。所以在用户搜索的时候,把搜索来的结果,有多少条纪录,还有搜索到的文章ID,纪录到另外的一个表里,tatols 就纪录了有多少条纪录。ids就纪录了那些文章的ID,搜索完后自动跳转到另外的页面,就直接调用这个表里的数据,用IN来查询,效率就很高了。可能我说不太清楚。具体你可以看看SAX的post.php文件的搜索部分。
发表评论