Devo creare una lumaca al volo o archiviare in DB?

Question

Una lumaca fa parte di un URL che descrive o titoli una pagina e di solito è una parola chiave ricca per quella pagina che migliora SEO. per esempio. In questo URL PHP/JS - Create thumbnails on the fly or store as files l'ultima sezione "php-js-create-thumbnails-on-the-fly-or-store-as-files" è lo slug.

Attualmente sto memorizzando lo slug per ogni pagina con il record della pagina nel DB. Lo slug viene generato dal campo Titolo quando la pagina viene generata e archiviata con la pagina. Tuttavia, sto pensando di generare la lumaca al volo nel caso in cui voglio cambiarla. Sto cercando di capire quale è meglio e cosa hanno fatto gli altri.

Finora mi è venuta in mente questi punti Pro per ognuno: slug

Store: - "Più veloce" processore non ha bisogno di generare ogni volta (viene generato una volta)

Genera al volo: - Flessibile (può regolare l'algoritmo di slug e non ha bisogno di rigenerare per l'intera tabella). - utilizza meno spazio nel DB - A meno di dati trasferiti dal DB App

Cos'altro mi sono perso e come/lo faresti?

EDIT:

Vorrei solo chiarire quello che sembra un equivoco nelle risposte. La lumaca non ha alcun effetto sull'atterraggio sulla pagina corretta. Per capirlo basta tagliare o manipolare qualsiasi parte della lumaca su questo sito. es .:

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

saranno tutti vi porterà alla stessa pagina. Lo slug non viene mai indicizzato.

Non avresti bisogno di salvare le vecchie lumache. Se sei atterrato su una pagina che ha avuto un "vecchio slug" allora puoi rilevarlo e basta fare un reindirizzamento 301 a quello "slugged" corretto. Negli esempi precedenti, se Stack Overflow l'ha implementato, quando è atterrato su uno qualsiasi dei link con slug troncati sopra, confronta lo slug nell'URL con quello generato dall'algoritmo slug corrente e se diverso lo farebbe un 301 reindirizzare alla stessa pagina ma con il nuovo slug.

Ricorda che tutti i link generati internamente sarebbero immediatamente utilizzando i nuovi collegamenti algoritmo e solo dall'esterno punta nella sarebbe utilizzando la vecchia lumaca.

Answer 1

Potrebbe essere necessario prendere in considerazione un'altra cosa, e se si desidera che l'utente/se stesso sia in grado di definire le proprie lumache. Forse l'algoritmo non è sempre sufficiente.

Se è così, è più o meno necessario memorizzarlo comunque nel database.

In caso contrario, non credo che importi molto, è possibile generarli al volo, ma se non si è sicuri se si desidera modificarli o non lasciarli essere nel database. Ai miei occhi non c'è un vero problema di prestazioni con entrambi i metodi (a meno che la generazione al volo sia molto lenta o qualcosa del genere).

Scegli quello più flessibile.

Answer 2

Non sarebbe una pessima idea cambiare gli slug per le pagine esistenti? Avrebbe rotto tutti i tuoi collegamenti per cominciare.

Modifica, seguendo chiarimento di Guy nella domanda: Hai ancora bisogno di prendere i vecchi lumache in considerazione. Ad esempio: se modifichi l'algoritmo di slug, Google potrebbe iniziare a visualizzare più versioni di ciascuna pagina e potresti subire una penalità di contenuto doppia o, al massimo, finire con la condivisione di PR e SERP tra più versioni della stessa pagina. Per evitare ciò, avresti bisogno di una versione canonica della pagina che reindirizzasse qualsiasi slog non canonico, e quindi avresti bisogno comunque dello slug canonico nel database.

Answer 3

Per la generazione di lumaca non credo che il tempo generazione dovrebbe essere un problema, a meno che il vostro algoritmo lumaca è follemente complicato! Allo stesso modo, lo spazio di archiviazione non sarà un problema.

Vorrei archiviare lo slug nel database per il semplice motivo che le lumache di solito fanno parte di un permalink e una volta che un permalink è uscito allo stato naturale dovrebbe essere considerato immutabile. Avere la capacità di cambiare una lumaca per i dati pubblicati sembra una cattiva idea.

Answer 4

Il modo migliore per gestire gli slug è quello di memorizzare solo la parte parlata dello slug nel database e mantenere la parte di routing con l'identificativo univoco per la generazione dinamica. Altrimenti (se memorizzi l'intero url o uri) nel database potrebbe diventare un compito enorme riscrivere prima tutti gli slug nel database se hai cambiato idea su come chiamarli.

Prendiamo questa domanda SO slug come ad esempio:

/domande/807.195/dovrei-i-create-a-lumaca-on-the-fly-o-store-in-db

E ' :

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

la parte dinamica è ovviamente:

/route/unique-ID/ 

E quella che avrei memorizzare nel database è il s parte un picco:

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

Questo permette di cambiare sempre idea circa il nome del percorso e fare il redirect corretto senza dover cercare all'interno del database prima e non si è costretti a fare i cambiamenti db. L'ID univoco è sempre l'ID univoco dei dati del database in modo che tu possa identificarlo correttamente e tu di causa sapere quali sono i tuoi percorsi.

E non dimenticare di impostare il tag canonico. Se si dà un'occhiata all'interno di questa pagina di codice che è lì:

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

Questo consente motori di ricerca per individuare il link alla pagina corretta e ignorare gli altri nel caso in cui si dispone di contenuti duplicati.