开发遇到了瓶颈

C 2019-1-31 1685

在和几个人在做一套有史以来最强的采集系统,先要有大致思路,其他模块都没啥问题,但是索引查重这一块出现了问题。其实就是数据库自身的排序问题,导致我们在作品名有字符和数字的时候,后面的数字无法按自然数排序。


举个例子:

大千世界1

大千世界11

大千世界2


这个查重项由于存在汉字,无法按int方式存储数据库。那么排序就会像上面一样,本来应该位于前面的2处在11后面,因为varchar排序是从前到后逐字的。如果只是查重倒好说,即便是varchar也可以一秒检索出重复项。但是功能设计的要求是用户可以按大千世界这个系列逐卷检索,类似于列表一样,这个就比较麻烦了。


有同学咨询了北大的学长,他说业内比较常用的做法就是字母替换,把大千世界后面的数字替换为字母a作为父索引(varchar),然后再建立子索引(int),把数字存储进去。类似于:

大千世界a-1

大千世界a-2

大千世界a-11


如果有多项关键字,类似于:

大千世界1

大千世界11

大千世界2

大千世界2后传1

大千世界2后传2

大千世界1后传21

大千世界后传2


则用多个字母替换,类似:

大千世界a-1

大千世界a-2

大千世界a-3

大千世界a后传b-21

大千世界a后传b-22

大千世界a后传b-121

大千世界后传a-2


这样似乎可以让他按特定顺序排列,但是注意上面大千世界1后转21,这个就无法排在大千世界2前面。现在正在思考怎么搞,是否该用一个特殊算法让每个数字项存在权重,从而实现绝对公平的排序。

最新回复 (1)
  • C 2019-1-31
    2

    其实最简单的是把他们出版发行时间都登记在册,不过这需要发帖者花费更多精力去核实。

    而且有时候也不知道大千世界前传还是后传先发行的,无法绝对切和真正的发行顺序。

返回
发新帖