Всё, да. А ещё нечитаемые и неинформативные. Они не задают никакого порядка: ни последовательности, ни иерархии. Глядя на 2 гуида я не могу понять, какой был создан раньше, у них порядок в какой-нибудь коллекции, кто у них родитель или какого они типа.
Как некоторое универсальное средство для ервого приближения — ок. Но в частных случаях всегда можно придумать что-то получше.
Здравствуйте, Ватакуси, Вы писали:
В>Они могут повторяться? В>Они длинные? В>Трудно запоминаемые?
Не то чтобы проблемы, но есть такие неприятные особенности:
1. не идут последовательно в отличии от int+sequence. Последовательные номера удобны бывают и при разработке и при отладке/анализе данных
2. сложно читаются и понимаются. Это неудобно при отладке и анализе данных.
В>Почему народ так сопротивляется их использовать?
Если кто и сопротивляется, то во многом, имхо, просто привычка "а мы всегда identity столбец делали, и все хорошо, зачем guid??"
Ну, например, звонит Вася Пете, глядя в распечатку на бумажке, и говорит: "проверь, есть там в твоей базе объект с идентификатором ...". А дальше что — диктовать весь ГУИД по буквам? Ну, можно, конечно, но неудобно.
И Пете на том конце тоже неудобно — гляда на этот ГУИД, непонятно, как сократить область поиска, чтобы быстро его найти.
В общем, как тут уже отмечали, во многих случаях и такой вариант годится, и его минусы будут несущественными. Но по-хорошему при проектировании надо задуматься (даже не с точки зрения отдельной программы, а с точки зрения системы в целом и людей, которые будут ей пользоваться): можно ли вместо ГУИДа использовать что-то более удобоваримое.
Кстати, лучше ГУИДа может оказаться даже ГУИД с каким-то семантически значимым префиксом (хотя это и длиннее).
Здравствуйте, Nuzhny, Вы писали:
N>Здравствуйте, Ватакуси, Вы писали:
N>Всё, да. А ещё нечитаемые и неинформативные. Они не задают никакого порядка: ни последовательности, ни иерархии. Глядя на 2 гуида я не могу понять, какой был создан раньше, у них порядок в какой-нибудь коллекции, кто у них родитель или какого они типа.
А вы в курсе что это и для чего нужно? Там, где они нужны не требуется ни знание их порядка, ни иерархии, ни какой был создан раньше, ни кто родитель, ни (боже упаси) какого они типа.
Попробуйте не делать костыли — без них на самом деле удобнее.
AS>А вы в курсе что это и для чего нужно? Там, где они нужны не требуется ни знание их порядка, ни иерархии, ни какой был создан раньше, ни кто родитель, ни (боже упаси) какого они типа.
Проблема в том, что часто бывает так: разработчик предположил, что знание их порядка, иерархии, хронологии и типов не требуется. А потом, блин, выясняется, что оказывается требуется.
Это к тому, что когда возникает вопрос "что взять в качестве идентификатора" — лучше этот вопрос решать не наскоком "а давайте возьмем ГУИД и не будем париться", а вместо этого надо тщательно подумать, все ли учли и не упустили ли чего важного.
Здравствуйте, AeroSun, Вы писали:
AS>А вы в курсе что это и для чего нужно? Там, где они нужны не требуется ни знание их порядка, ни иерархии, ни какой был создан раньше, ни кто родитель, ни (боже упаси) какого они типа. AS>Попробуйте не делать костыли — без них на самом деле удобнее.
В курсе. Требуется.
Например, я когда-то занимался ручной генерацией проектов для MS VS. И там проекты идентифицируются гуидами. В результате так получилось, что в процессе разработки и отладки инструмента я многие гуиды на память помнил. А были бы они разумными, то не пришлось бы.
Я, кажется, понимаю твою озицию. Типа гуид создан не для человека, а для компьютера. Но это всё хрень, потому что обязательно наступит момент, когда с ними придётся ковыряться именно человеку.
Здравствуйте, Ватакуси, Вы писали:
В>Почему народ так сопротивляется их использовать?
GUID это глобальный уникальный идентификатор. Ключевое слово здесь глобальный в противовес локальному.
GUID (Globally Unique Identifier) — статистически уникальный 128-битный идентификатор. Его главная особенность — уникальность, которая позволяет создавать расширяемые сервисы и приложения без опасения конфликтов, вызванных совпадением идентификаторов.
Теперь о том, где это использовать:
UUID (англ. universally unique identifier «универсальный уникальный идентификатор») — это стандарт идентификации, используемый в создании программного обеспечения, стандартизированный Open Software Foundation (OSF) как часть DCE — среды распределённых вычислений.
Основное назначение UUID — это позволить распределённым системам уникально идентифицировать информацию без центра координации.
Наиболее распространённым использованием данного стандарта является Globally Unique Identifier (GUID) фирмы Microsoft.
Стоит ещё обратить внимание на такое понятие как URI.
URI (/ˌjuː ɑːr ˈaɪ/ англ. Uniform Resource Identifier) — унифицированный (единообразный) идентификатор ресурса. URI — последовательность символов, идентифицирующая абстрактный или физический ресурс. Ранее назывался Universal Resource Identifier — универсальный идентификатор ресурса.
Слово universal и universally неявно связывают понятия UUID(GUID) и URI. URI же в свою очередь состоит из URL и URN.
URN (англ. Uniform Resource Name) — единообразное название (имя) ресурса.
Структура URN
Единообразные имена ресурсов имеют следующую структуру:
<URN> ::= "urn:" <NID> ":" <NSS>
В этой записи:
<NID>
идентификатор пространства имён (англ. Namespace Identifier); представляет собой синтаксическую интерпретацию NSS, не чувствителен к регистру.
<NSS>
строка из определённого пространства имён (англ. Namespace Specific String); если в этой строке содержатся символы не из набора ASCII, то они должны быть закодированы в Юникоде (UTF-8) и предварены (каждый из них) знаком процента «%» (подробнее см. URL).
Использование GUID в качестве UUID фактически создаёт собственное пространство имён NID, в котором GUID выступает в роли строки NSS из этого пространства имён.
А теперь вопрос, зачем людям так заморачиваться для локальных (в противовес глобальным) или централизованных (в противовес распределённым) ресурсов, например, таких как строки в базе данных. Инкрементный целочисленный счётчик вероятно будет работать быстрее. В современных компьютерах 64 бита, то есть не просто будет исчерпать диапазон 264, если вообще возможно.
Лично я думаю, что там где нужно GUID используют, а там где нет, не используют.
Здравствуйте, Nuzhny, Вы писали:
N>Всё, да. А ещё нечитаемые и неинформативные. Они не задают никакого порядка: ни последовательности, ни иерархии. Глядя на 2 гуида я не могу понять, какой был создан раньше, у них порядок в какой-нибудь коллекции, кто у них родитель или какого они типа. N>Как некоторое универсальное средство для ервого приближения — ок. Но в частных случаях всегда можно придумать что-то получше.
Ничего не мешает кодировать в GUID и иерархию и порядок. 16 байтов это довольно много.
Здравствуйте, Ватакуси, Вы писали:
В>Они могут повторяться? В>Они длинные? В>Трудно запоминаемые? В>Почему народ так сопротивляется их использовать?
Хорошее — уникальность на стороне клиента. Т.е. единообразные модели (не сохраненная модель, как и сохранненная, содержит id с разумным значением) и какая-то экономия на sequence при вставке.
Плохое — занимают много места в базе и недружелюбны к людям.
Здравствуйте, L.K., Вы писали:
LK>Например: 2020-12-RUS-MSK-a75gb912ca5.... LK>Гуид остаётся случайным и уникальным, при этом видны год и месяц создания, страна и город.
Но становится длинной строкой вместо просто 16 байт. Если БД поддерживает нативно guid, то разница в размере ключей и индексов может быть очень большой, особенно на "узких" табилцах.
Здравствуйте, Nuzhny, Вы писали:
N> А ещё нечитаемые и неинформативные.
вот это очень-очень да.
N>Они не задают никакого порядка: ни последовательности, ни иерархии. Глядя на 2 гуида я не могу понять, какой был создан раньше, у них порядок в какой-нибудь коллекции, кто у них родитель или какого они типа.
Этот подход уже приближается к естественному первичному ключу. Когда ключ сам имеет некоторый бизнес-смысл. Guid-ы же хороши как синтетический ключ. Который просто для внутренней работы БД — идентификация записей, join
Максимально такой синтетический.
Я лично предпочитаю именно использование синтетических ключей в БД. А где надо — дополнять таблицу еще столбцом типа code, где уже можно кодировать иерархию, происхождение и все прочее.
Использование же кода как основного ключа может выйти неожиданно боком, если потребуется вдруг реализовать какое-ниубдь логическое удаление, или захочется вдруг поменять структуру этого кода (т.к. сменились правила формирования иерархии, например) и подобное все. Модификация значений первичного ключа сложнее из-за связей чем модификация значений другого столбца таблицы.
Здравствуйте, vsb, Вы писали:
vsb>Ничего не мешает кодировать в GUID и иерархию и порядок. 16 байтов это довольно много.
Это будет некорректным использованием гуидов. Куда как лучше для этого сделать поле своего формата.
