Длина URL

Ничего спорного. По ID продукт мгновенно находится в БД, без всяких ухищрений.

Про смену  движка – отдельный разговор. Там вообще куча проблем. В остальных случаях больших проблем нет.

Не знаю, что там гугл писал – это опять же другая история. А в той же Джумле испокон века ID писался в URL именно по соображениям удобства работы с БД, без каких-либо указок Гугла.

Нет никаких "групп" ID. SCU - это доп. поле данных, а не ID. ID в базе  - это чётко обозначенная сущность. "Искусственный ID" по большому счёту не является ID с т.з. базы.

Поэтому я и говорил... то что говорил в комменте Sitealert-у.

При том, что я комментировал "зачем это делалось". А  ТС просто интересуется длинной урла как факта ранжирования.

:) Если Вы такие умные - почему строем не ходите? (с) анек.

Я не говорил что невозможно - я говорил, что это может стать проблемой. Т.е. как минимум доп. расходами финансов и времени.

У современных общепринятых CMS таких проблем действительно уже давно нет, но мне наверное везет частенько сотрудничать с командами, где сайты на самописных CMS и там бывает всякое :)

Если бы не было ЧПУ - тогда так и было бы. А тут по любому надо или полностью работать с ЧПУ либо парсить урл, вычленяя цифры. А с учетом того, что с другими адресами/сущностными где нет цифр движок уже как-то ж работает, то городить второй вариант как-то не логично и нецелесообразно.

Не, я не говорю что такого не может быть - я говорю, что это не так однозначно. Т.е. "легче" - далеко не всегда.

Я уже объяснил Антонию принципы строения базы и контента в ней. Не думал что и тебе надо было это разжевывать...

В джумле испокон веков не было ЧПУ :). Потом появился модуль SEF, который, если мне не изменяет память являлся костылём (таким же как модуль ЧПУ в SMF напр) - там не нормальный роутинг, а виртуальная страница, в которую инклудился контент. И да, в этом случае и нужен был ID тк по другому ещё сложнее определить что инклудить (писать сопоставления в базу, создавая тормоза напр).

ЗЫ. И у джумлы ИДшники писались в начало слага, а не в конце.

Ok. Я бы сказал - доп. задачей. Любые направленные рабочие действия - это и есть набор задач. Но каких-то отличительных проблем здесь я действительно не вижу. 

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

Так там не про ранжирование, там про датировку материалов в учете Гугл.Новостей.

Сейчас там нет таких проблем, да и SEF компонентов великое множество.

Давай я попробую ещё раз.

Если в адресах не используется ID (реальный ID), то перенос контента не взывает никаких дополнительных проблем/работ.

Если это они есть, то в случае пересвоения  ID (что происходит в подавляющем большинстве движков) придётся писать немало костылей - начиная от смены правил ЧПУ, переходя от реального ID к искусственному. В ином случае - писать кучу 301. Но это может быть вообще невозможно. И дело не в объёме, а.. догадаешься почему или объяснить? ;)

Всё смешалось в доме Облонских :)

"Там" и не про ранжирование (про ражирование спрашивал ТС), и не про датировку (это частный случай). Там про цифры в урле для гуглоньса.

Это скорее я тебе смогу разжевать, чем ты мне.

Что-то несусветное городишь. И да, я с Джумлой работаю с самой первой версии. Так что можешь не рассказывать, что там было и что там есть.

Это детали. Несущественные.

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

Есть входные данные  www.site.ru/krovati/krovat-anjelika-id1486

Товар "Кровать Анжелика", ID-1486, категория - Кровати.

Категория вводится структурно, вложенность товара в категорию - понятно.

Далее, если себе гипотетически представить, что исходных ID в БД нет, а есть просто запись целевого рабочего url-а, то очевидно URL последовательность разбирается в логике до id - название товара, транслитом, где "-" замена пробела, а цифровая последовательность после id без пробела - номер ID. Фактическое соответствие по факту заданной строки между товаром и ID последовательностью есть - это связка заносится в БД.

Далее точно также, на новом сайте восстановить данный адрес не составляет труда (при условии совпадающей транслитерации) без всяких там 301-х редиректов. Новые ID сгенерированные CMS-ой в URL-е не выводить, а выводить те, что мы спарсили из исходной строчки (тогда это уже даже не ID, а просто параметр в строке URL-а). Так чего ж там такого особенного-то?

Если мы говорим о каком-то начинающем вебмастере, который приглядел новый движок и хочет c одной CMS платформы перевести свой товарный саттелит на другую - здесь у него могут возникнут вполне конкретные проблемы, которые он может и не решить без посторонней помощи. Но если это живой бизнес и нанятый опытный программист, то эта задача из разряда начального уровня - спарсить, разобрать, занести нужные данные в таблицы БД, сформировать новые URL-ы и далее для контроля - сравнить перечень URL-ов старого сайта с новым. При точном построчном совпадении задача выполнена.

:) Поэтому я и сказал, что Гугл.Ньюс нам не нужен, у нас другой случай. Изначально вообще речь была про необходимость сокращения URL-а, на что в первых же комментариях я дал ответ.