动态搜索,产生搜索结果链接(反向路由)

发布于 2024-11-07 06:37:35 字数 1022 浏览 0 评论 0原文

只是拉皮条我的 cms 并尝试简化一些常见的任务,例如搜索。 cms有许多不同的模块,每个模块都可以用动态路由进行屏蔽。

整个系统非常坚固并且非常灵活,但这正是搜索结果页面令人头痛的地方。

为了保持灵活性,我将基本数据扔到我的搜索类中,如下所示:

$search->addTable('content', array('title', 'excerpt', 'body', 'meta_keywords', 'meta_description'));
$search->addTable('event', array('title', 'description', 'tags'));

然后,我的搜索类从这些变量生成一个 sql 查询,它将很好地找到结果(呃,也许“nicely”现在不是最好的词,因为结果集包含来自不同表的行,所以我无法分辨哪一行属于哪个表,因为所有结果都在一个数组中)

问题是当我想显示我需要处理的结果页面为每个结果制作适当的 url,这是非常困难的,因为我上面提到的系统灵活性(任何内容/模块都可以用任何东西屏蔽)。

我知道我的问题非常本地化,可能太模糊,无法以当前的形式回答,所以我会尝试澄清一下我的问题。我不会向您询问最佳实践或问题的简单答案,但如果您能为我提供有关这些基本问题的一些好的提示,我将非常感激:

  • 看起来生成单个查询并不是最好的方法,因为我无法分辨哪一行属于哪个表(不同的表可能意味着不同的 url 制作方法)。另一种方法是单独查询每个表并将结果存储在多维数组中(键为表名)。据我所知,在 foreach 循环中查询 sql 不是一种可接受的方法。是否可以在单个查询中标记每个结果行以反映其表名称?
  • 如果我不为这些结果制作真实的(屏蔽的、路由的)网址,但我会显示非常基本的网址,例如(example.com/content/nice-url-slug),这会损害我的搜索引擎优化吗?谷歌可能会因为重复而惩罚我的网站 - 这对我来说不好。

一如既往,请询问而不是单击“关闭”,也许我可以进一步澄清该情况。谢谢你,法布里克。

Just pimping my cms and trying to simplify some usual tasks like searching. The cms has many different modules, each of these modules can be masked with dynamic routes.

The whole system is pretty solid and really flexible but this is where search result pages are causing a headache.

To keep things flexible i'm throwing basic data to my search class like this:

$search->addTable('content', array('title', 'excerpt', 'body', 'meta_keywords', 'meta_description'));
$search->addTable('event', array('title', 'description', 'tags'));

Then, my search class is generating one sql query from these variables which will find the results nicely (er, maybe 'nicely' isn't the best word now because the result set contains rows from different tables so i can't tell which row belongs to which table because all of the results are in a single array)

The problem is when i want to display the results page i need to take care of crafting appropriate urls for each result which is very difficult because of the systems flexibility i mentioned above (any content/module can be masked with anything).

I understand my question is very localized and maybe too vague to answer it in its current form so i'll try to clarify my problems a bit. I don't ask you about best practices or a simple answer for my problem but i'd be very thankful if you can provide me some good tips about these fundamental issues:

  • Looks like producing a single query isn't the best approach because i can't tell which row belongs to which table (different tables could mean different url crafting methods). Another approach would be to query each table separately and store results in a multidimensional array (table name for the key). AFAIK querying sql within a foreach loop isn't an accepted method. Is it possible to mark each result row to reflect it's table name within a single query?
  • Will it hurt my SEO if i won't craft the real (masked, routed) urls for these results but i display the very basic ones like (example.com/content/nice-url-slug). Google may punish my sites because of duplicates - which isn't okay for me.

As always please ask instead of clicking close maybe i can clarify the scenario a bit more. Thank you, fabrik.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

眼泪淡了忧伤 2024-11-14 06:37:35

简短的回答是,执行多个查询是完全可以的,只要我们不是在谈论数十个查询。这也意味着返回的结果将是一组集合,其结构类似于上面的数组,表名称是该表中一组结果的关键。

我必须弄清楚代码中某个地方组装了该数组。组装后,您可以循环遍历它并对每个表精确查询一次。在该循环中,您拥有所需的所有上下文:表名称。

然后,将该数组的数组返回给将其组装成结果的任何客户端。如果表名足以构建 URL,那么就可以开始了。如果您需要有关每个表的更多信息,例如其 ID 列的名称,请构造结果数组以包含有关每个表的所需元数据。

总的来说,看起来您的结构很好,并且在试图避免多次查询时遇到了麻烦。不用担心这个。多个查询的问题是,当相同 *表*在循环中被一遍又一遍地查询时,当这是普遍的设计模式时,性能就会下降。

The short answer is that it is perfectly OK to do multiple queries, so long as we're not talking dozens of them. This also means the results returned are going to be a set of sets, structured like your array above, with a table name being the key to a set of results from that table.

I have to figure that there is a point somewhere in the code where that array is assembled. When it is assembled, you can loop through it and query each table exactly once. Within that loop you have all of the context you need: the table name.

Then you return that array of arrays to whatever client is assembling it into results. If the tablename is enough to construct the URL you are good to go. If you need more information about each table, such as what its ID column is named, structure the results array to contain needed meta-data about each table.

Overall, it looks like you've got this structured well, and are getting tripped up trying to avoid multiple queries. Don't worry about that. The problem with multiple queries is when the same *table* is queried over and over in a loop, when that is the pervasive design pattern then performance tanks.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文