UUID

[Yoskaldyr]

Создам еще одну тему
Плюсы UUID и так известны (ид известно до создания сущности и т.д.) по сравнению с популярным автоинкрементом/секвенцией.

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

Просто хочется везде поизбавляться от автоинкрементов, но что сделать с url-ами нормальное - даже не знаю. Дублировать цифровой идентификатор, но тогда зачем uuid?

P.S. Все обсуждение здесь на форуме связанное с UUID было только о том нужно оно или нет и обсуждение плюсов и минусов, но ничего насчет роутинга и uuid в урл-е не было.

 

[jonjonson]

А вы не путаете UUID и slug?

 

[Yoskaldyr]

А вы не путаете UUID и slug

UUID в слаге если так понятнее.
как пример с потолка:
$route->addRule( '/news/[^/]+-{id}/', ....)
и $id в формате uuid

 

[jonjonson]

UUID в slug не бывает.
Это вообще разные вещи.
slug вообще может не содержать случайных последовательностей символов.

 

[AmdY]

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

uri,entity, id, active
blog/about-me, post, 777, false
blog/about, post, 777, true

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

ПО поводу id или uuid для баз данных у которых нет id, просто заводили отдельную таблицу, где хранили счётчик. И вместо генерации id, делали запрос к базе, инкрементили счётчик и получали свой вручную инкременченный id. Но такое возможно только если все ходят через одну дырку и на lheub[ клиентах не надо гененрировать id.

 

[Yoskaldyr]

На такиз проектах обычно отдельно держат таблицу, где урл мэпится на id-uuid

Как раз так и делается для части урлов. Но проекты почти всегда с тонной пользовательского контениа - форумы, блоги и тому подобное и страниц больше ляма. Понятно что какая-то часть модерируется и в ней может правится url и другая мета информация, но основная - нет и урл должен генерироваться по каким-то правилам. Для таких случаев оставлять числовой id в урл-е это компромисс с которым большинство сеошников соглашается, ведь заголовки могут меняться пользователем и надо поддерживать редиректы со старух урлов на новые и т.д.
Понятно что цифровой id в урл тоже не айс, но учитывая специфику пользовательского контента - как вариант, сойдет.
С uuid уже не прокатывает.
Генерировать цифровой id в добавок к uuid - тогда зачем вообще uuid для данных типов сущностей?

 

[AnrDaemon]

А кто сказал, что uuid тебе вообще нужны?…

 

[Yoskaldyr]

@AnrDaemon Ну у uuid есть свои явные плюсы, при работе с сущностями, с логированием и т.п. Во многих частях это бы значительно упростило код. Но вот точно так же явно что не везде их можно применить и id в урл - один из примеров

 

[AnrDaemon]

Ну

Не нукай, не запряг…
У всего есть

свои явные плюсы

, вопрос в том, какие плюсы более актуальны для конкретного применения.
Если ты можешь позволить себе использовать ID в URL, явно числовой ID будет предпочтительнее.
А с другой стороны, может и UUID быть предпочтительнее, если тебе надо общаться только с JS фронтом.

 

[grigori]

@Yoskaldyr ты смешиваешь много несвязанных тем. Автоинкременты, UUID, числа в URL, SEO, постановка задачи - это разные темы, которые не связаны.
Ты просто рассказать о своей жизни хочешь, или есть конкретные вопросы?

> uuid слишком длинный и мусорный для сео
Это утверждение противоречит здравому смыслу. Поисковики реагируют на ключевые слова, а не на длину или UUID.
> Дублировать цифровой идентификатор
в чем конкретно проблема?
> Как генерировать чистые линки
определи критерий чистоты

 

[Yoskaldyr]

Это утверждение противоречит здравому смыслу. Поисковики реагируют на ключевые слова, а не на длину или UUID.

Никто не знает точно алгоритмы ранжирования поисковиков, я уверен даже сами работники не знают на 100% как работает из ранжирование. То что ключевые слова из урл-а влияют на ранжирование - это факт, но вот как влияет на это ранжирование мусор в урл-е - тут хз (uuid это явный мусор с точки зрения текста). И любая непонятная хрень - это команда фас для сеошников. Я лично не перевариваю сеошников, но с этим приходится жить.

в чем конкретно проблема?

а проблемы нет, но тогда и uuid нахрен сдались, если все равно нужен автоинкремент/секвенция. Тогда получается собираем все минусы и uuid и минусы автонкремента.

определи критерий чистоты

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

 

[Adelf]

Если важно сео - делай слаги и другие сео активности.
А так - что числовые айди, что uuid - разницы нет.

 

[grigori]

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

Вопрос есть какой-нибудь?

 

[fixxxer]

Ну, я могу понять нежелание видеть UUID в урлах. Чисто эстетическое. Но это вполне решается мапой slug -> uuid, не вижу прям проблемы какой-то в этом.

 

[Yoskaldyr]

Но это вполне решается мапой slug -> uuid

300К слагов? Многовато будет....

 

[AmdY]

Это экономия на спичках.

 

[grigori]

300К слагов? Многовато будет....

по какому критерию? со скольки начинается много?
мапинг slug->uuid работает прямой выборкой или из таблицы по UK, или из редиса по ключу, сложность вида O(log n) - чего может быть многовато в этом алгоритме?

 

[fixxxer]

Много? Это вообще нисколько, если индекс или key value storage.
Давайте еще обсудим проблемы шаред хостинга за 50 рублей, ога.

 

[Yoskaldyr]

@fixxxer Тут все зависит от того что за меп будет.
Если слаг - это большой символьный кусок урла (например тайтл контента) - то индекс может быть отнюдь не мелкий даже для нормального сервера, особенно если 300К это обычно старт (а есть и 5-6М). К тому же в таком случае надо писать дополнительный и бесполезный с точки зрения бизнес логики код для уникализации слага.
Если слаг - это число, то тут уже обычный автоинкремент/секвенция и зачем тогда uuid?

Во вторых нужно 2 индекса как по id (слаг) так и наоборот по uuid. И если брать mysql, то не важно где будет храниться слаг в основной таблице сущности или в отдельной. Индекс будет не мелкий. Самый минимальный вариант это примари индекс как число, а второй индекс по uuid.

И кстати только что понял что учитывая особенности индексов в innodb в таблицах в 90% случаев нельзя делать uuid примари, если планируются хотя бы несколько индексов в этой таблице, т.е. примари всегда делать какое либо неиспользуемое поле (все доп индексы содержат примари индекс, по крайней мере в innodb). И вот в этом случае еще больше стоит вопрос в целесообразности по крайней мере на мускуле.

 

[fixxxer]

MySQL :: MySQL 8.0 Reference Manual :: 14.23 Miscellaneous Functions

dev.mysql.com

А вообще я бы задал вопрос о целесообразности использования мыскля