Pourquoi SlugField () à Django?

Django a models.SlugField() ce qui nous aide à créer des urls à la recherche cool. Ma question est pourquoi le spécifier comme un champ

supposons que j'ai ce modèle

 class Blog(models.Model):
    title = models.CharField()

et si je veux ajouter un slug, j'ai juste l'utiliser

 class Blog(models.Model):
    title = models.CharField()

    def title_slug(self):
       return slugify(self.title)

url j'ai juste l'utiliser

(r'^blog/(?P<id>d+)/(?P<slug>[-w]+)/$', 'app.views.blog_view'),

et vues

def blog_view(request, id ,slug):
    get_object_or_404(Blog, pk=id)
    ...

url

example.com/blog/23/why-iam-here/

il y a trois choses qui me font adopter cette méthode

  1. Slug field ne vient pas avec l'unicité implicite.
  2. get_object_or_404(Blog, pk=id) doit être plus rapide que get_object_or_404(Blog, slug=slug).
  3. L'ajout d'un champ de limaces aux modèles existants implique une migration de données.

alors pourquoi SlugField ()? , mis à part le coût de la production dynamique slug, quels sont les inconvénients de la méthode ci-dessus ?

39
demandé sur Vini.g.fer 2013-07-05 22:57:26

2 réponses

pourquoi SlugField () à Django? Parce que:

  1. c'est convivial pour les humains (p. ex. /blog/ au lieu de /1/).
  2. il est bon de créer une cohérence dans le titre, l'en-tête et L'URL.

Le grand inconvénient de votre limace générée dynamiquement, accepter les limaces dans urls.py et ne pas utiliser la balle pour obtenir le bon objet? C'est une mauvaise conception.

si vous fournissez et acceptez des slugs, mais ne les comparez pas, alors vous avez plusieurs URLs retournant la même contenu. Donc /1/utile-limace/ et /1/ceci-est-un-bs-limace/ retourneront tous les deux la même page.

c'est mauvais parce que ça ne rend pas la vie facile aux humains. Vos visiteurs doivent fournir un identifiant et quelque chose qui est redondant. Les pages dupliquées sont un cauchemar pour les moteurs de recherche. La page est-elle la bonne? Les pages dupliquées se retrouveront avec un rang bas. Voir https://support.google.com/webmasters/answer/40349?hl=en (dernier p)

Vous peut prétendre que vous mettez en œuvre vos propres liens magnifiquement générés de manière cohérente, mais les gens et les bots deviner des URLs tout le temps (voir vos logfiles). Quand on accepte toutes les balles, les humains et les robots ont toujours raison.

également l'économie d'une balle au db économise la puissance de traitement. Vous générez la balle une fois et vous la réutilisez. Qu'est-ce qui sera plus (dans)efficace de chercher la balle ou de la générer à chaque fois?

les champs Slug dans l'administrateur sont utiles pour donner aux éditeurs l'occasion de modifier la limace. Peut-être pour fournir des informations supplémentaires qui ne sont pas dans le titre mais qui valent la peine d'être mentionnées.

Bonus: pour mettre à jour les données migrées:

from django.template.defaultfilters import slugify

for obj in Blog.objects.filter(slug=""):
    obj.slug = slugify(obj.title)
    obj.save()
32
répondu allcaps 2015-10-22 14:59:45

Slug field ne vient pas avec l'unicité implicite.

il n'y a pas d'unicité implicite avec un CharField. Vous devez spécifier unique=True si vous voulez vous assurer que chaque ligne est unique au niveau de DB. Vous devez faire cela avec à la fois un CharField et SlugField donc pas d'avantage à

get_object_or_404(Blog, pk=id) doit être plus rapide que get_object_or_404 (Blog, slug=slug).

Il n' peut-être une très légère différence due à un indice sur votre clé primaire, mais c'est probablement négligeable. Cela n'a rien à voir avec l'utilisation d'un CharField et SlugField - vous venez de créer une URL différente qui prend un id et utilisent cela pour faire la recherche.

L'ajout d'un champ de limaces aux modèles existants implique une migration de données.

Ajouter un CharField à un modèle existant a également exigé une migration de données de sorte qu'il n'y a aucun avantage ici.


SlugFields sont tout simplement CharField avec un peu de validation supplémentaire. regardez le code. Vous enfreignez la règle d'or de Django - ne vous répétez pas.

de plus, si vous utilisez un CharField vous n'obtenez aucune validation au niveau de la forme, donc vous pouvez très facilement créer un "slug" qui ne se conforme pas à la validation slugs, c'est-à-dire qu'il pourrait avoir des espaces ou des caractères qui ne sont pas autorisés dans une URL.

Aussi avec cette approche, si vous changer votre titre, votre URL a changé et maintenant, tous vos anciens liens sont morts. Avoir un champ de balle empêche cela.

Vous faites plus de soucis pour vous - même-utiliser le SlugField

10
répondu Timmy O'Mahony 2014-05-19 14:18:06