我应该动态创建一个 slug 还是存储在数据库中？
slug 是 URL 的一部分，用于描述或标题页面，并且通常包含丰富的关键字，可改善该页面的 SEO。 例如在此 URL PHP/JS - 创建缩略图动态或存储为文件 最后一部分“php-js-create-thumbnails-on-the-fly-or-store-as-files”是 slug。
目前，我正在将每个页面的 slug 以及该页面的记录存储在数据库中。 slug 是在生成页面时从 Title 字段生成的，并与页面一起存储。 但是，我正在考虑动态生成 slug，以防我想更改它。 我正在努力找出哪个更好以及其他人做了什么。
到目前为止，我已经为每个人提出了这些优点：
存储 slug： - “更快”的处理器不需要每次都生成它（生成一次）
动态生成： - 灵活（可以调整 slug 算法并且不需要重新生成整个表）。 - 使用更少的数据库空间 - 从数据库传输到应用程序的数据更少
我还错过了什么以及您会如何做？
编辑：
我只是想澄清一下答案中看起来有什么误解。 slug 对于登陆正确的页面没有影响。 要理解这一点，只需砍掉或弄碎本网站上的蛞蝓的任何部分。 例如：
都会将您带到同一页面。 slug 永远不会被索引。
你不需要保存旧的蛞蝓。 如果您登陆的页面有“旧 slug”，那么您可以检测到这一点，然后只需执行 301 重定向到正确的“slug”页面即可。 在上面的示例中，如果 Stack Overflow 实现了它，那么当您登陆上面任何带有截断 slug 的链接时，它会将 url 中的 slug 与当前 slug 算法生成的 slug 进行比较，如果不同，则会执行 301重定向到同一页面，但使用新的 slug。
请记住，所有内部生成的链接将立即使用新算法，只有来自外部指向的链接才会使用旧的 slug。
A slug is part of a URL that describes or titles a page and is usually keyword rich for that page improving SEO. e.g. In this URL PHP/JS - Create thumbnails on the fly or store as files that last section "php-js-create-thumbnails-on-the-fly-or-store-as-files" is the slug.
Currently I am storing the slug for each page with the page's record in the DB. The slug is generated from the Title field when the page is generated and stored with the page. However, I'm considering generating the slug on the fly in case I want to change it. I'm trying to work out which is better and what others have done.
So far I've come up with these pro points for each one:
Store slug:
- "Faster" processor doesn't need to generate it each time (is generated once)
Generate-on-the fly:
- Flexible (can adjust slug algorithm and don't need to regen for whole table).
- Uses less space in DB
- Less data transferred from DB to App
What else have I missed and how do/would you do it?
EDIT:
I'd just like to clarify what looks like a misunderstanding in the answers. The slug has no effect on landing on the correct page. To understand this just chop off or mangle any part of the slug on this site. e.g.:
PHP/JS - Create thumbnails on the fly or store as files
PHP/JS - Create thumbnails on the fly or store as files
PHP/JS - Create thumbnails on the fly or store as files
will all take you to the same page. The slug is never indexed.
You wouldn't need to save the old slugs. If you landed on a page which had an "old slug" then you can detected that and just do a 301 redirect to the correctly "slugged" one. In the examples above, if Stack Overflow implemented it, then when you landed on any of the links with truncated slugs above, it would compare the slug in the url to the one generated by the current slug algorithm and if different it would do a 301 redirect to the same page but with the new slug.
Remember that all internally generated links would immediately be using the new algorithm and only links from outside pointing in would be using the old slug.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
更改现有页面的slugs不是一个非常糟糕的主意吗？ 首先它会破坏你所有的内链。
编辑，按照盖伊在问题中的澄清：您仍然需要考虑旧的蛞蝓。 例如：如果您更改了 slug 算法，Google 可能会开始看到每个页面的多个版本，并且您可能会遭受重复内容的惩罚，或者最多最终会在同一页面的多个版本之间共享 PR 和 SERP。 为了避免这种情况，您需要任何非规范 slug 重定向到的页面的规范版本 - 因此无论如何您都需要数据库中的规范 slug。
Wouldn't changing the slugs for existing pages be a really bad idea? It would break all your inlinks for a start.
Edit, following Guy's clarification in the question: You still need to take old slugs into account. For instance: if you change your slug algorithm Google could start to see multiple versions of each page, and you could suffer a duplicate content penalty, or at best end up sharing PR and SERPs between multiple versions of the same page. To avoid that, you'd need a canonical version of the page that any non-canonical slugs redirected to - and hence you'd need the canonical slug in the database anyway.
您可能需要考虑另一件事，如果您希望用户/您自己能够定义自己的 slugs，该怎么办？ 也许算法并不总是足够的。
如果是这样，您或多或少需要将其存储在数据库中。
如果不是，我认为这并不重要，您可以即时生成它们，但如果您不确定是否要更改它们或不让它们存在于数据库中。 在我看来，这两种方法都不存在真正的性能问题（除非动态生成非常慢或类似的情况）。
选择最灵活的一项。
You might need to take another thing into consideration, what if you want the user/yourself to be able to define their own slugs. Maybe the algorithm isn't always sufficient.
If so you more or less need to store it in the database anyhow.
If not I don't think it matters much, you could generate them on the fly, but if you are unsure whether you want to change them or not let them be in the database. In my eyes there is no real performance issue with either method (unless the on-the-fly generation is very slow or something like that).
Choose the one which is the most flexible.
对于 slug 生成，我认为生成时间不应该是一个问题，除非你的 slug 算法非常复杂！ 同样，存储空间也不会成为问题。
我会将 slug 存储在数据库中，原因很简单，slug 通常构成永久链接的一部分，一旦永久链接出现在野外，它应该被认为是不可变的。 能够更改已发布数据的数据块似乎是一个坏主意。
For slug generation I don't think that generation time should be an issue, unless your slug algorithm is insanely complicated! Similarly, storage space won't be an issue.
I would store the slug in the database for the simple reason that slugs usually form part of a permalink and once a permalink is out in the wild it should be considered immutable. Having the ability to change a slug for published data seems like a bad idea.
处理 slug 的最佳方法是仅将 slug 的说话部分存储在数据库中，并保留具有唯一标识符的路由部分以用于动态生成。 否则（如果您将整个 url 或 uri 存储在数据库中），如果您改变了如何调用它们的想法，那么首先重写数据库中的所有 slugs 可能会成为一项艰巨的任务。
让我们以这个问题 SO slug 为例：
/questions/807195/should-i-create-a-slug-on-the-fly-or-store-in-db
它是：
动态部分显然是：
我会的存储在数据库中是最重要的部分：
这允许您始终改变对路线名称的想法并执行正确的重定向，而不必先查看数据库内部，并且您不必被迫进行数据库更改。 唯一 ID 始终是您的数据库数据唯一 ID，因此您可以正确识别它，并且您当然知道您的路线是什么。
并且不要忘记设置规范标签。 如果您查看此页面代码，它就在那里：
这允许搜索引擎识别正确的页面链接，并在您有重复内容时忽略其他页面链接。
The best way to handle slugs is to only store the speaking part of the slug in the database and keep the routing part with the unique identifier for dynamic generation. Otherwise (if you store the whole url or uri) in the database it might become a massive task to rewrite all the slugs in the database first if you changed your mind about how to call them.
Let's take this questions SO slug as example:
/questions/807195/should-i-create-a-slug-on-the-fly-or-store-in-db
it's:
The dynamic part is obviously:
And the one I would store in the database is the speaking part:
This allows you to always change your mind about the route's name and do the proper redirects without to have to look inside the database first and you're not forced to do db changes. The unique Id is always your database data unique Id so you can identify it correctly and you of cause know what your routes are.
And don't forget to set the canonical tag. If you take a look inside this page code it's there:
This allows search engines to identify the correct page link and ignore others in case you have duplicate content.