Про UUID

[vitus_wagner]

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

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

1. В БД хранятся данные из реального мира. Поэтому как ни изворачивайся с естественным ключом, а нарушения уникальности будут. Ибо реальный мир всегда сложнее модели.
2. В БД есть ссылочная целостность. И если у тебя естественный ключ получается килобайт этак в восемь, то лучше завести 32-битный суррогатный, чем клонировать по паре десятков таблиц эти 8К на запись.

Comments

[gul_kiev]

Например, номер банковской карты - это по сути и есть нечто вроде суррогатного ключа или UUID.
Действительно, нет внятного объяснения, чем эта карточка отличается от другой карточки, сгенерированной в предыдущую миллисекунду. Ничем не отличается, они одинаковые, но их нужно различать. Как говорят в Индии, "same-same but different".

[juan_gandhi]

О нет, номер карты не суррогатен.

[gul_kiev]

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

[morthan2006]

Самый впечатляющий пример использования GUID-ов в моей практике.

Комплект технической документации на часть системы, которую мы сейчас поддерживаем. Все заголовки сделаны GUID-ами. Куча сносок «см. документ такой-то, раздел [нечитаемый GUID]».

Аргументация, как я понимаю, заключается в уникальности GUID-ов. Типа, обычные разделы могут переименовываться, а GUID переименовывать бессмысленно.

[inkelyad]

Куча сносок «см. документ такой-то, раздел [нечитаемый GUID]».

Вообще говоря, не вижу ничего плохого (и даже одобряю), если сноска - кликабельная и можно немедленно в тот раздел попасть.

[morthan2006]

Вероятно, разработчик тоже так думал. Сноска кликабельная, попасть в раздел нельзя (документ, на который ссылаются, то ли утерян много лет назад, то ли поменял ID, то ли переименовался). Остаётся догадываться о содержании раздела по его названию. С другими документами, в которых названия человекочитаемы, такое получается значительно лучше.

[inkelyad]

В этом случае тоже не согласен с тем, что это неудобно. Когда линк недоступен, то этот UUID просто ищется полнотекстовым поиском по всему массиву доступных документов. Единственное но - это что такой UUID-название должен фигурировать и непосредственно в текстах заголовков разделов, а не только как идентификатор для вытаскивания из базы данных. Если этого не сделали - то ошибка именно в этом.

Другое дело, что человекочетабельное название может дать какие-нибудь похожие доки или доки от других версий. Это может как помогать так и мешать.

[morthan2006]

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

Опять же, есть большая вероятность, что сноску читать не надо, потому что информация уже известна. В случае человекочитаемого заголовка это ясно сразу. Поиск по GUID-у потребует времени, а когда выяснится, что его можно было не делать, это вызовет раздражение.

Молодым разработчикам я обычно говорю так: «Если есть вероятность, что это будет читать человек, то это должно быть человекочитаемо. Если читать будет машина, то лучше всё равно сделать человекочитаемым — вдруг когда-нибудь человеку придётся это читать?»

[yurikhan]

UUID’ы и есть суррогатные ключи. С тем дополнительным соображением, что UUID’ы достаточно безопасно и эффективно назначать в распределённой мульти-мастер-системе, тогда как, например, порядковые номера — только в централизованной. И ещё UUID’ы (4-й версии) труднопредсказуемы и практически неперебираемы, тогда как порядковые номера — легко (и это может иметь безопасностные последствия).

[jahr]

Использование UUID это, на мой взгляд, низкий класс, плохая работа.
У разных решений - разные приоритеты.) Имена могут быть понятными, надежными и децентрализованными, но не одновременно, можно выбрать только 2 из 3 (https://en.wikipedia.org/wiki/Zooko%27s_triangle ). UUID - secure и decentralised

[vitus_wagner]

У меня есть убеждение, что непонятное не может быть надежным. Вот по определению. Потому что сломается всё что угодно, но правильно починить понятное - легче.

[juan_gandhi]

Справедливо. Но обычно дизайнерам не впаришь эти простые истины.

[nataraj]

Слушая рассказ про массовое автоматическое внедрение постгреса (SaaS) почерпнул оттуда противопоставление Pet и Cattle. При массовой обработки у тебя объекты cattle, и ты им присваиваешь ничего не значащие номера или иные суррогатные ключи. Не различая их никак. Если же у тебя объект имеет имя или личную конуру, то это уже Pet, и о массовой обработке тут речи не идет.

[vitus_wagner]

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

Где массовая обработка, там конвейер, и глубокое разделение труда. Там должны работать роботы (которые сами по себе могут уже быть pets).

[nataraj]

И далее размышляя на тему:

Кол-во жестких дисков в моем домашнем сервере такое, что еще вполне уместно давать им имена собственные, но их комбинация с количеством SATA разъемов на матери делает уже крайне неудобным ориентироваться на номер устройства в системе. Кто из них какой /dev/sdX поди разбери...

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

[burbilog]

Семантика в идентификаторах -- дерьмо. Которое потом обязательно кусает за задницу.

И начинается придумывание -- а тут у нас надо идентификатор регионов присобачить. А тут у нас отдельно, еще мегаполисы, давайте буковку М пришпилим. Что, идентификаторы цифровые? А ну сделали символьными, быстро, насрать нам, нам вот такая нумерация нужна. А тут у нас филиал в Казахстане, ой, ну давайте KZ сделаем. Нет там регионов как в России? И ломаются скрипты? Ну что ж вы не предусмотрели десять лет назад, что мы кроме Земли, еще на Луне и Марсе работать будем.

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

[p_govorun]

А вот история из реального мира. Место действия -- Франция.

Объясняю ситуацию. В Донецке этих Александров Козлов примерно как донов Педров в Бразилии. Это был точно не я. Какая у вас на этот случай предусмотрена процедура? А процедуры нет никакой. Потому что ситуация и правда во Франции невозможная.

Во-первых, нет такой концентрации имён (где-то была статистика, что имя «Елена» использовалось для более чем 10% родившихся в какой-то год девочек, и «Наталья» от неё ненамного отставала — для сравнение, мега-популярный в 2010 году «Nathan» не дотянулся даже до 1%). Концентрации фамилий тоже (за сто лет во Франции было вдвое меньше Martin, чем Смирновых только в одном году в России). Более того, традиционно во Франции дают несколько имён. И даже если на чековой книжке у вас значится «Emmanuel Macron», в паспорте будет прописано что-то типа «Emmanuel Jean-Michel Frédéric Macron». У человека, подписавшего чек, было только одно имя «Александр». У меня, впрочем, тоже.

Во-вторых, практически нет больших «мест рождения» — Донецк в 1975 году это больше миллиона населения. Во Франции города-миллионеры (стоп! почему я говорю о Париже во множественном числе?) нарезаны на arrondissement, и в свидетельстве о рождения будет указано не Paris, а Paris 15.

Всё это вместе взятое на несколько порядков снижает вероятность встретить полного тёзку. Я не удивлюсь, если окажется, что и на уровне мэрии, записывающей рождения, есть какой-то контроль: простите, но сегодня уже зарегистрировали одного Александра Козлова. Припишете ему какое-то дополнительное имя?
То есть, и без того редкая ситуация совпадения видимых идентификаторов обычно разруливается предъявлением документа с дополнительными именами. А полное совпадение всего не предусмотрено.

[inkelyad]

Тут уместно вспомнить старое Falsehoods Programmers Believe About Names и добавить, что имена бывают не только у людей. Название места рождения тоже, например, измениться может.

[nataraj]

Название места рождения тоже, например, измениться может.

В электронном заявлении на шенгенскую визу нельзя выбрать страну рождения СССР. Хотя по факту я именно в СССР родился. Российская Федерация появилась позднее.

[edo-rus.livejournal.com]

Использование UUID это, на мой взгляд, низкий класс, плохая работа

категорически не согласен

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

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