使用 slug 而不是 ID 来获取记录
我目前正在尝试在处理诸如获取标有特定标签、类别或类似内容的记录之类的情况时找到最佳方法（在可用性和性能方面）。
一个好方法（我想要做的方法）是使用标签/类别 slug 获取记录，因此 URL 看起来像：
http://stackoverflow.com/questions/tagged/language-agnostic
通过 slug 获取记录，这看起来比：
http://stackoverflow.com/questions/tag/789/language-agnostic
通过 ID 获取并在后面添加 slug 更好它对搜索引擎更友好。 这在性能方面更好，因为通过整数 ID 获取数据比字符串更快。 (cmiiw)
现在，使用像这样的数据库模式：
posts post_to_tags tags
----- ------------ ----
id id id
title post_id name
content tag_id slug
... ...
我做得对吗？ 为了避免性能问题，我需要了解哪些陷阱或最佳实践吗？ （例如，标签不应超过 10,000 条记录，或标签段不应超过 n 个字符，或其他）
提前致谢。
I'm currently trying to find the best way (in term of usability and performance) when dealing with a situation like fetching records tagged with a specific tag, or category, or something like that.
A good way (the way I wanted to do), would be to fetch records with the tag/category slug, so the URL would look like :
http://stackoverflow.com/questions/tagged/language-agnostic
fetching records by slug, which looks better than :
http://stackoverflow.com/questions/tag/789/language-agnostic
fetching by ID and adding the slug behind so it's more search-engine friendly. This one is better performance-wise, because fetching data by an integer ID would be faster than a string. (cmiiw)
Now, with a db schema like :
posts post_to_tags tags
----- ------------ ----
id id id
title post_id name
content tag_id slug
... ...
am I doing it right ? Is there pitfall or best-practices that I need to know to avoid performance problems ? (eg. tags should not exceed 10,000 records, or tag slug should not exceed n characters, or something else)
Thanks in advance.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
使用第一个 URL 样式和当前的数据库设计，您可以执行以下操作：
只要对 tag.slug 建立索引，这应该非常高效，几乎与
With the first URL style and your current db design, you can do this:
As long as tags.slug is indexed, this should be very efficient, hardly any different from
第一个更好，但是可以改变子弹吗？ 在这种情况下，您需要有一个重定向表（例如“some-article-about-dogs”现在是“article-about-dogs-and-cats”）。
The first one is better, but can the slugs possibly be changed? In that case you'd need to have a redirect table (e.g. "some-article-about-dogs" is now "article-about-dogs-and-cats").