Dois-je créer un slug à la volée ou le stocker dans DB?

Question

Un slug fait partie d'une URL qui décrit ou intitule une page. Il s'agit généralement d'un mot clé riche pour améliorer le référencement de cette page. par exemple. Dans cette URL PHP / JS - Créer des vignettes sur voler ou stocker en tant que fichiers cette dernière section "php-js-create-thumbnails-on-fly-ou-store-as-files" est la limace.

Actuellement, je stocke le slug pour chaque page avec l'enregistrement de la page dans la base de données. Le slug est généré à partir du champ Titre lorsque la page est générée et stockée avec la page. Cependant, j'envisage de générer la limace à la volée au cas où je souhaiterais la changer. J'essaie de déterminer lequel est le meilleur et ce que d'autres ont fait.

Jusqu'à présent, j'ai mis au point ces points professionnels pour chacun d'entre eux:

Store limace: - " Faster " le processeur n'a pas besoin de le générer à chaque fois (est généré une fois)

Générer à la volée: - Flexible (peut ajuster l'algorithme slug et ne nécessite pas de régénération pour la table entière). - Utilise moins d'espace dans la base de données - Moins de données transférées d'une base de données à une application

Qu'est-ce que j'ai oublié de plus et comment le faites-vous / le feriez-vous?

EDIT:

Je voudrais juste clarifier ce qui ressemble à un malentendu dans les réponses. La limace n'a aucun effet sur l'atterrissage sur la bonne page. Pour comprendre cela, il suffit de couper ou de réduire à néant une partie de la limace sur ce site. par exemple:

PHP / JS - Créer des vignettes sur la mouche ou stocker en tant que fichiers

PHP / JS - Créez des vignettes à la volée ou stockez-les sous forme de fichiers

PHP / JS - Création de vignettes à la volée ou stockage dans des fichiers

vous mènera tous à la même page. La limace n'est jamais indexée.

Vous n’auriez pas besoin de sauver les vieilles limaces. Si vous avez atterri sur une page contenant un "vieux slug" vous pouvez alors détecter cela et effectuer une redirection 301 vers le fichier "slugged" correctement. un. Dans les exemples ci-dessus, si Stack Overflow l'implémentait, alors lorsque vous atterrissiez sur l'un des liens contenant des slugs tronqués ci-dessus, il comparait le slug de l'URL à celui généré par l'algorithme actuel du slug. 301 rediriger vers la même page mais avec le nouveau slug.

N'oubliez pas que tous les liens générés en interne utiliseraient immédiatement le nouvel algorithme et que seuls les liens de l'extérieur pointant dans utiliseraient l'ancien slug.

Answer 1

Vous devrez peut-être prendre en considération une autre chose. Si vous souhaitez que l'utilisateur / vous-même soit capable de définir ses propres slug. Peut-être que l'algorithme n'est pas toujours suffisant.

Si oui, vous avez plus ou moins besoin de le stocker de toute façon dans la base de données.

Sinon, je pense que cela importe peu, vous pouvez les générer à la volée, mais si vous ne savez pas si vous souhaitez les modifier ou non, laissez-les dans la base de données. À mes yeux, il n'y a pas de réel problème de performances avec l'une ou l'autre méthode (à moins que la génération à la volée soit très lente ou quelque chose comme ça).

Choisissez celui qui est le plus flexible.

Answer 2

Ne pas changer les slugs des pages existantes ne serait-il pas une très mauvaise idée? Cela commencerait par casser tous vos liens entrants.

Modifier, en suivant la clarification de Guy dans la question: vous devez toujours prendre en compte les anciennes limaces. Par exemple, si vous modifiez votre algorithme de slug, Google pourrait commencer à voir plusieurs versions de chaque page et vous pourriez subir une pénalité de contenu en double ou, au mieux, partager des relations publiques et des stratégies de réplication entre plusieurs versions de la même page. Pour éviter cela, vous avez besoin d’une version canonique de la page vers laquelle les slugs non canoniques sont redirigés - et vous aurez donc besoin du slug canonique dans la base de données.

Answer 3

Pour la génération de slug, je ne pense pas que le temps de génération devrait être un problème, à moins que votre algorithme de slug ne soit incroyablement compliqué! De même, l'espace de stockage ne sera pas un problème.

Je voudrais stocker la limace dans la base de données pour la simple raison que les limaces font généralement partie d’un lien permanent, ce qui devrait être considéré comme immuable. Avoir la possibilité de changer un slug pour des données publiées semble être une mauvaise idée.

Answer 4

La meilleure façon de gérer les slugs consiste à ne stocker que la partie parlante du slug dans la base de données et à conserver la partie de routage avec l'identifiant unique pour la génération dynamique. Sinon (si vous stockez l'intégralité de l'URL ou de l'URI) dans la base de données, la réécriture de toutes les limaces de la base de données peut s'avérer une tâche énorme si vous changez d'avis sur la façon de les appeler.

Prenons cette question SO slug comme exemple:

/ questions / 807195 / devriez-je créer un slug-on-the-fly-ou-store-in-db

c'est:

/route/unique-ID/the-speaking-part-thats-not-so-important

La partie dynamique est évidemment:

/route/unique-ID/

Et celui que je voudrais stocker dans la base de données est la partie parlante:

the-speaking-part-thats-not-so-important

Cela vous permet de toujours changer d’avis sur le nom de la route et de faire les redirections appropriées sans avoir à regarder d’abord dans la base de données et vous n’êtes pas obligé de faire des changements de base de données. L'identifiant unique est toujours l'identifiant unique de vos données de base de données afin que vous puissiez l'identifier correctement et vous permettre de savoir quels sont vos itinéraires.

Et n'oubliez pas de définir la balise canonique. Si vous regardez à l'intérieur de cette page, vous y trouverez le code:

<link rel="canonical" href="http://stackoverflow.com/questions/807195/should-i-create-a-slug-on-the-fly-or-store-in-db" />

Cela permet aux moteurs de recherche d'identifier le lien de page correct et d'ignorer les autres au cas où le contenu serait dupliqué.