Должен ли я создать слаг на лету или хранить в БД?

Question

Плагин - это часть URL-адреса, которая описывает или озаглавляет страницу, и обычно содержит много ключевых слов для этой страницы, улучшая SEO. например В этом URL PHP / JS - создавайте миниатюры на лету или сохраняйте их в виде файлов , где последний раздел «php-js-create-thumbnails-on-the-fly-or-store-as-files» является слизняк.

В настоящее время я храню слаг для каждой страницы с записью страницы в БД. Плагин генерируется из поля Название, когда страница генерируется и сохраняется вместе со страницей. Тем не менее, я рассматриваю возможность создания пули на лету на случай, если захочу ее заменить. Я пытаюсь понять, что лучше и что сделали другие.

До сих пор я придумывал эти про очки для каждого:

Хранить слизняк: - «Быстрее» процессор не должен генерировать его каждый раз (генерируется один раз)

Генерация на лету: - Гибкий (можно настроить алгоритм слагов и не нужно регенерировать для всей таблицы). - использует меньше места в БД - Меньше данных, передаваемых из БД в приложение

Что еще я пропустил и как / вы бы это сделали?

EDIT:

Я просто хотел бы уточнить, как выглядит недоразумение в ответах. Слаг не влияет на посадку на правильной странице. Чтобы понять это, просто отрубите или покалечите любую часть пули на этом сайте. e.g.:

PHP / JS - Создание миниатюр на лету или сохранение в виде файлов

PHP / JS - Создание миниатюр на лету или сохранение в виде файлов

PHP / JS - Создание миниатюр на лету или сохранение в виде файлов

приведет вас на одну и ту же страницу. Слизняк никогда не индексируется.

Вам не нужно спасать старых слизней. Если вы попали на страницу, на которой был «старый слаг», то вы можете обнаружить это и просто сделать перенаправление 301 на правильно «слизняк». В приведенных выше примерах, если в Stack Overflow реализовано это, то, когда вы окажетесь на любой из ссылок с усеченными слагами, приведенными выше, он будет сравнивать слаг в URL-адресе с тем, который генерируется текущим алгоритмом слага, и если он будет отличаться, он сделает 301 перенаправить на ту же страницу, но с новым слагом.

Помните, что все внутренне сгенерированные ссылки будут немедленно использовать новый алгоритм, и только ссылки извне, указывающие, будут использовать старый слаг.

Answer 1

Не будет ли изменение слагов для существующих страниц действительно плохой идеей? Это сломало бы все ваши ссылки для начала.

Отредактируйте, следуя разъяснениям Гая в вопросе: Вам все еще нужно учитывать старых слизней. Например: если вы измените свой алгоритм slug, Google может начать видеть несколько версий каждой страницы, и вы можете понести штраф за дублирование контента, или, в лучшем случае, в конечном итоге разделить PR и SERP между несколькими версиями одной и той же страницы. Чтобы избежать этого, вам понадобится каноническая версия страницы, на которую перенаправляются все неканонические слагы - и, следовательно, вам все равно понадобится канонический слаг в базе данных.

Answer 2

Возможно, вам придется принять во внимание еще одну вещь: что если вы хотите, чтобы пользователь / вы сами могли определять свои собственные слагы. Может быть, алгоритм не всегда достаточен.

Если это так, вам все равно нужно более или менее сохранить его в базе данных.

Если нет, то я не думаю, что это имеет большое значение, вы можете сгенерировать их на лету, но если вы не уверены, хотите ли вы изменить их или нет, оставьте их в базе данных. На мой взгляд, нет никакой реальной проблемы с производительностью ни с одним из методов (если генерация на лету очень медленная или что-то в этом роде).

Выберите наиболее гибкий вариант.

Answer 3

Для генерации пули я не думаю, что время генерации должно быть проблемой, если ваш алгоритм пули не слишком сложен! Аналогично, место для хранения не будет проблемой.

Я бы сохранил слаг в базе данных по той простой причине, что слизни обычно образуют часть постоянной ссылки, и как только постоянная ссылка отсутствует, ее следует считать неизменной. Возможность менять слаг для опубликованных данных кажется плохой идеей.

Answer 4

Лучший способ обработки слагов - хранить только говорящую часть слагов в базе данных и сохранять часть маршрутизации с уникальным идентификатором для динамической генерации. В противном случае (если вы сохраните весь url или uri) в базе данных, может оказаться сложной задачей сначала переписать все слагы в базе данных, если вы передумали о том, как их вызывать.

Давайте возьмем эти вопросы ТАК, как слаг, например:

/ вопросы / 807195 / должны-я-Create-A-слизняка-на-лету или-магазин-в-дб

это:

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

Динамическая часть, очевидно:

/route/unique-ID/

А в базе данных я бы сохранил говорящую часть:

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

Это позволяет вам всегда передумать относительно названия маршрута и делать правильные перенаправления без необходимости сначала заглядывать в базу данных, и вы не обязаны вносить изменения в БД. Уникальный идентификатор всегда является уникальным идентификатором данных вашей базы данных, поэтому вы можете правильно его идентифицировать, и вы точно знаете, каковы ваши маршруты.

И не забудьте установить канонический тег. Если вы заглянете внутрь кода этой страницы, он там:

<link rel="canonical" href="/720870/dolzhen-li-ya-sozdat-slag-na-letu-ili-hranit-v-bd" />

Это позволяет поисковым системам идентифицировать правильную ссылку на страницу и игнорировать другие, если у вас есть дублированный контент.