保存搜索结果的数据库结构

我目前在社交网站上工作。保存搜索结果的数据库结构

我的老板最近有想法显示搜索结果随机而不是正常结果（注册日期）。这个问题很简单明显：如果你从一个页面到另一个页面，每次随着列表被随机化，每次都会显示不同的结果。

我有想法存储在数据库+饼干这样的结果：

包含$ _ POST请求的序列化版本（需要的，如果我们想要做一个重新排序）
饼干这将作为基础的搜索表ID =>搜索（ID，用户_id, creation _date）
这将存储结果和它们的顺序的表=>搜索_results (search_id, order, user _id）

流程图看起来像这样的事情：

每个搜索后，我存放“在那里”到一个cookie或会话
然后我抹去“搜索”
以前的搜索。然后我删除在“searches_results”
以前的结果的话，我行插入“搜索”为重点
然后我插入每个用户一行到“searches_results”
最后，我将用户重定向到somethink LIK e？search_id = [search_key]

这里存在一个很大的缺陷：性能......它可能使系统或降低或非常慢。

任何想法什么是最好的结构呢？

来源

2009-01-21 Erick

如果不是随机排序，而是通过一些函数来排序，其中的顺序是已知和可重复的，只是非显而易见的？您可以使用搜索查询中的一些数据来创建这样的功能，以使其重复显示更加不明显。这样，您可以在结果中来回查看，并始终获得您期望的结果。音乐播放器将这种功能用于他们的随机播放功能（这样，如果您点击后退，则会播放前一首歌曲，如果再次单击下一首歌曲，则会回到起点位置）。我相信你可以通过一些函数来完成这个... bitwise XORing带有一些常量（来自查询）的ID值，然后通过结果数字进行排序可能就足够了。我任意选择异或，因为它是一个非常简单的函数，可以为您提供可重复和非显而易见的结果。

来源

2009-01-21 21:27:07 rmeador

哼，这可能会伎俩。我将不得不检查MySQL如何对此做出反应。（感谢您的评论提示我大多习惯于非线程的论坛 – Erick 2009-01-21 21:54:47

哼，也许，但不是异或运算符只会说如果它是一个OR排他？我的意思是，就我所知，这里没有数学运算。

来源

2009-01-21 21:32:53 Erick

我对此感到抱歉，XOR既是一个逻辑运算符，也是一个按位运算符，我已经用解释的链接更新了我的答案。，在StackOverflow上，发布一个答案作为对另一个答案的答复是不被接受的，你应该更新问题，或者对答案进行评论。 – rmeador 2009-01-21 21:43:39

对不起，我知道这并没有帮助，但我不明白你的老板为什么要这样做？

我知道如果我在社交网络上搜索某个人，那么我只希望结果按相关性和相关性排序。我认为随机结果会让用户感到沮丧，但也许这就是我。

例如，如果我搜索“John Smith”，那么第一批第一批结果最好是名为“John Smith”的人。然后在结果附近给我看类似的名字。我不想搜索“约翰史密斯”并获得“乔恩史密瑟斯”作为我的第二个结果。

来源

2009-01-21 21:58:09

嗯，我与马特问“为什么？”

我认为rmeador也有很好的建议。你可以随机排序一个不同的领域或某种算法。仅从上次更新的DESC/ASC的排列或其他结果字段。

其他选项可能是首次执行初始搜索，并只返回相关ID，然后将完整ID的字符串存储在数据库中，然后每个后续页面将对这些ID进行查找。

我的两分钱。

我可以看到一个场景，其中随机结果集很有用，但不适用于搜索，而是用于浏览简介或艺术家或本地事件。它为那些传统导向搜索中不会出现的内容提供了更多的曝光机会。

来源

2009-01-22 00:29:36 jerebear

保存搜索结果的数据库结构

回答

相关问题