复杂的搜索解决方法
首先，这不一定是一个问题。但我真的想知道您对这种搜索“模式”的性能和可能出现的问题的看法。
我需要在带有大量过滤器、范围和规则的多个表上创建一个非常复杂的搜索...并且我意识到我可以创建如下内容：
- 提交搜索表单
- 在内部我运行每个过滤器并逐步逻辑（这可能需要几秒钟）
- 在找到所有匹配记录（我想要的结果）后，我在我的
searches表上创建一条记录，生成此搜索的标记（基于在搜索参数上），例如 86f7e437faa5 并保存所有匹配的记录 ID - 将访问者重定向到类似 mysite.com/search?token=86f7e437faa5 的页面
并且，在结果页面上，我只需要发现什么搜索我说的是结果 ID 的分页（从 searches 表中检索）。
这将使刷新&分页速度更快，因为我不需要在每个页面浏览量上运行所有搜索逻辑。如果用户更改过滤器或搜索条件，我将返回步骤 2 并生成新的搜索令牌。
我从未见过教程或相关内容，但我认为 BBForum 或 Invision 等一些论坛就是这样做的，对吗？搜索后，我重定向到类似 search.php?id=1231 的内容（我在 URL 上或 POST 参数内没有看到搜索参数）。
这个“令牌”的持续时间不会超过30min~1h..所以“静态搜索”只是出于性能原因。
您对此有何看法？会起作用吗？有什么考虑吗？ :)
Before anything, this is not necessarily a question.. But I really want to know your opinion about the performance and possible problems of this "mode" of search.
I need to create a really complex search on multiple tables with lots of filters, ranges and rules... And I realize that I can create something like this:
- Submit the search form
- Internally I run every filter and logic step-by-step (this may take some seconds)
- After I find all the matching records (the result that I want) I create a record on my
searchestable generating a token of this search (based on the search params) like 86f7e437faa5 and save all the matching records IDs - Redirect the visitor to a page like mysite.com/search?token=86f7e437faa5
And, on the results page I only need to discover what search i'm talking about and page the results IDs (retrieved from the searches table).
This will make the refresh & pagination much faster since I don't need to run all the search logic on every pageview. And if the user change a filter or search criteria, I go back to step 2 and generate a new search token.
I never saw a tutorial or something about this, but I think that's wat some forums like BBForum or Invision do with search, right? After the search i'm redirect to sometihng like search.php?id=1231 (I don't see the search params on the URL or inside the POST args).
This "token" will no last longer than 30min~1h.. So the "static search" is just for performance reasons.
What do you think about this? It'll work? Any consideration? :)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
您的系统可能有特殊令牌（例如 86f7e437faa5）并缓存搜索请求。对于系统效率和可扩展性来说，这是一种非常有用的机制。
但用户必须根据可用性原则查看所有参数。
因此，在服务器端动态生成参数的哈希值将是一个很好的解决方案。系统检查搜索表中是否存在生成的哈希值，如果找到则返回结果。
如果没有哈希，系统从基表中进行查询并将新结果保存到搜索表中。
Your system may have special token like 86f7e437faa5 and cache search requests. It's a very useful mechanism for system efficiency and scalability.
But user must see all parameters in accordance with usability principles.
So generating hash of parameters on the fly on server-side will be a good solution. System checks existanse of genereted hash in the searches table and returns result if found.
If no hash, system makes query from base tables and save new result into searches table.
对我来说似乎很合逻辑。
话虽如此，根据您的应用程序的描述，您是否考虑过使用 Sphinx。无论表和/或过滤器和/或规则的数量有多少，所有耗时的工作都在索引中，并且是在场景之前/之后完成的。过滤/规则/字段/表格都是在事后快速且即时完成的。
因此，与您的情况类似，Sphinx 可以非常快速地为您提供一组 ID，因为所有艰苦的工作都已预先完成。
Seems logical enough to me.
Having said that, given the description of you application, have you considered using Sphinx. Regardless of the number of tables and/or filters and/or rules, all that time consuming work is in the indexing, and is done beforehand/behind the scene. The filtering/rules/fields/tables is all done quickly and on the fly after the fact.
So, similar to your situation, Sphinx could give you your set of ID's very quickly, since all the hard work was pre-done.
TiuTalk，
您是否考虑将搜索保存在“搜索”表中？如果是这样，请记住，对于给定的一组参数，基于参数生成的令牌将保持不变，并持续一段时间。如果您的搜索库经常更改，则不能依赖已保存的搜索，因为它可能会返回过时的结果。否则，这似乎是一个很好的解决方案。
我宁愿将令牌基于用户会话。你怎么认为？
@g0nc1n
TiuTalk,
Are you considering keeping searches saved on your "searches" table? If so, remember that your param-based generated token will remain the same for a given set of parameters, lasting in time. If your search base is frequently altered, you can't rely on saved searches, as it may return outdated results. Otherwise, it seems a good solution at all.
I'd rather base the token on the user session. What do you think?
@g0nc1n
如果您可以控制您的服务器（例如在 VPS 中），Sphinx 似乎是一个不错的解决方案。
如果您不这样做并且简单的全文搜索对您来说还不够，我想这是一个很好的解决方案。
但对我来说，它似乎与带有缓存的分页搜索没有什么不同。它似乎比使用简单的 url 引用缓存的分页搜索更好。但仍然存在搜索保持静态的问题。我建议您时常刷新已保存的搜索。Sphinx seems to be a nice solution if you have control of your server (in a VPS for example).
If you don't and a simple Full Text Search isn't enough for you, I guess this is a nice solution.
But it seems not so different to me than a paginated search with caching. It seems better than a paginated search with simple url refered caching. But you still have the problem of the searches remaining static. I recommend you flush the saved searches from time to time.