Создание уникального идентификатора (GUID) – Useful Developers Tools

Что такое guid

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

Ну, по-порядку: GUID – Globally Unique Identifier – шестнадцатибайтный двоичный массив, обеспечивающий, по-идее, идентификаторы, которые не повторяются нигде и никогда.

“Нигде” обеспечивается включением в код MAC-адреса сетевого интерфейса (при его отсутствии – какого-то суррогата).

“Никогда” – это генерация меток времени с точностью до 1 нс размером 8 байт. На самом деле, наверное, никто эту наносекунду не ловит. Вероятно, младшие разряды метки просто как-то увеличиваются по мере генерации новых кодов, хотя Microsoft пишет, что значение берётся из внутреннего таймера центрального процессора (BOL):

“…The Transact-SQL NEWID function and the application API functions and methods generate new uniqueidentifier values from the identification number of their network card plus a unique number from the CPU clock…”

Чем отличается GUID от UUID?

UUID – универсально-уникальный идентификатор по данным всемирной организации стандартизации версии RFC4122. Этот термин используется в спецификациях протокола Windows как синоним GUID в 1С. Он должен быть полностью технически совместим с RFC4122.

Как получить уникальный идентификатор зная UUID в 1С

Итак, как же получить GUID зная UUID в 1С?

В конструкторе запроса необходимо создать запрос:

СправочникСсылка=Справочники.ИмяСправочника.НайтиПоНаименованию(«Наименование»);
GUID=СправочникСсылка.УникальныйИдентификатор()

Для установления соответствия объектов разных БД используется GUID.

Необходимо указать узел обмена и тип объекта (склад, договор, контрагент и т.д.). В «источнике» базы данных нужно указать объект, с которым будет устанавливаться соответствие с объектом из «приемника» БД.

Специалист компании ООО «Кодерлайн» 

Ирина Оргина.

Guid и access’97

Всё написанное ниже относится к русской версии с установленным пакетом обновления 2 (SR-2) и типу данных “Числовой” или “Счетчик” с размером поля “код репликации” для таблиц JET. Хотя, присоединённые таблицы MS SQL Server ведут себя аналогично.

Создаётся впечатление, что 97-й Access не был изначально рассчитан на активное использование этого типа данных. Он описывается как массив байтов (vbByte vbArray), то есть отдельного типа не предусмотрено. Различные варианты получения содержимого элементов управления и полей наборов записей дают самые разнообразные результаты:

Такое многообразие форм напоминает природу тропического леса и так же грозит массой сюрпризов. Однако постепенно всё это запоминается и начинает давать предсказуемые результаты.

Для взаимного преобразования представлений служит пара функций: GuidFromString и StringFromGuid.

Первая из них принимает в качестве аргумента строку, представляющую GUID. Допускается как минимум два варианта: “{6F9619FF-8B86-D011-B42D-00C04FC964FF}” и “{guid {6F9619FF-8B86-D011-B42D-00C04FC964FF}}”. Возвращает GUID в формате всё того же байтового массива.

Вторая принимает GUID исключительно в формате байтового массива и выдаёт строку вида “{guid {6F9619FF-8B86-D011-B42D-00C04FC964FF}}”. Если передать в эту функцию любую строку, то на выходе получается эта же самая строка. Ошибка не возникает.

Если надо получить GUID в виде строки из 16 символов, то можно использовать вместо GuidFromString функцию Eval.

Преобразования позволяют обойти некоторые ограничения Access’а. Например попытка перейти на нужную запись в форме обычным способом

            Set RS = Me.RecordsetClone

            RS.FindFirst "FirmID = " & Me.OpenArgs

            Me.Bookmark = RS.Bookmark

приведет к ошибке 3614 “Не допускается применение поля GUID в выражении условия отбора для метода Find”.

А вот такой вариант сработает

            Set RS = Me.RecordsetClone

            RS.FindFirst "StringFromGuid(FirmID) = " & Me.OpenArgs

            Me.Bookmark = RS.Bookmark

Ссылки по теме

Как получить уникальный идентификатор объекта, guid?

 ГУИДССЫЛКИ	= СсылкаНаОбъект.УникальныйИдентификатор();
// или
НоменклатураСсылка = Справочники.Номенклатура.НайтиПоКоду("00013");
Если НЕ НоменклатураСсылка.Пустая() Тогда
Сообщить("GUID = "   НоменклатураСсылка.УникальныйИдентификатор());
КонецЕсли; 

  Запрос = Новый Запрос;
Запрос.Текст = "ВЫБРАТЬ
|    Номенклатура.НаименованиеПолное,
|    Номенклатура.ЕдиницаИзмерения,
|    Номенклатура.СтавкаНДС,
|    Номенклатура.НоменклатурнаяГруппа,
|    Номенклатура.СчетУчетаЗапасов,
|    Номенклатура.СчетУчетаЗатрат,
|    Номенклатура.Ссылка, 
|    Номенклатура.ЭтоГруппа
| ИЗ
|    Справочник.Номенклатура КАК Номенклатура"; 
РезультатЗапроса = Запрос.Выполнить();
СпрОбъект = РезультатЗапроса.Выбрать();    
Пока СпрОбъект.Следующий()  Цикл
СтрокаУИ = Объект.XMLСтрока(СпрОбъект.Ссылка);
GUID = Справочники.Номенклатура.ПолучитьСсылку(Новый УникальныйИдентификатор(СокрЛП(СтрокаУИ)));          
КонецЦикла;

 Инфо = СоздатьОбъект("AddIn.V7SysInfo");
ГлобальноУникальныйИдентификатор = Инфо.СоздатьGUID();

 Функция СоздатьGUID()
TypeLib = CreateObject("Scriptlet.TypeLib");
NewGUID = TypeLib.Guid();
TypeLib = "";
Возврат NewGUID;
КонецФункции    
//******************************************* 
Процедура Сформировать()
g=СоздатьGUID();
Сообщить("Создан GUID: " g);
КонецПроцедуры

 Если Док_Источник.ВыбратьДокументы(ВыбНачПериода,ВыбКонПериода) = 1 Тогда
Пока Док_Источник.ПолучитьДокумент() = 1 Цикл
Объект = БазаОле.ЗначениеВстрокуВнутр(Док_Источник.ТекущийДокумент());
ИдентификаторДокумента = СокрЛП(ПолучитьИД(Объект));
//   Для примера Объект возвращает {"O","0","0","3114","0","0","    258156CB "}, 
//   а ПолучитьИД(объект) = 258156CB
КонецЦикла; 

Практическое использование guid

Теперь о главном: не так важно, как GUID делается. Гораздо важнее оценить возможность его использования в качестве первичного ключа. Совершенно очевидно, что в четыре раза больший размер поля приводит к более быстрому увеличению размеров таблиц. Ещё несколько лет назад это имело существенное значение, но сейчас, когда как дисковая, так и оперативная память значительно подешевела и увеличилась в объёмах, данный фактор можно просто исключить из рассмотрения (но только для клиент-серверных систем!).

Другое дело – быстродействие. Это стоит проверить, но только сначала определимся с местом и назначением идентификаторов в общей структуре данных. Идентификаторы – GUID’ы можно использовать только для связи таблиц и однозначного указания нужной строки. Всё. Никакого другого смысла в них искать не следует.

Исходя из этого строился тестовый набор из двух таблиц:

Master:

        MasterID  Код репликации

        Criteria  Длинное целое

Detail:

        DetailID  Код репликации

        MasterID  Код репликации

        Value     Денежный

Вторая аналогичная пара таблиц отличалась только типом полей – идентификаторов. Там они были целые (4 байта). Количество записей не очень большое: на каждую из 10000 в таблице Master приходилось 10 в таблице Detail. Итого 110000 записей в каждой паре. Тест проводился на относительно слабеньком компьютере (PIII-450, 128Mb RAM, Windows’98 SE) с русским Access’97 SR-2.

Для получения GUID’ов использовалось поле типа “Счетчик” с размером “код репликации”, а идентификаторов целого типа – “Счетчик” с размером “Длинное целое”. Поле Criteria заполнялось случайными челыми числами от 0 до 9, Value – случайными значениями денежного типа порядка 10000.

Далее выполнялся простейший запрос, суммирующий Value из таблицы Detail по одинаковым значениям Criteria из таблицы Master.

SELECT Master.Criteria, SUM(Detail.Value) AS Summ

FROM Detail INNER JOIN Master ON Detail.MasterID = Master.MasterID

GROUP BY Master.Criteria

Так вот: применение GUID’ов привело к увеличению времени выполнения запроса почти в 4 раза (с 3 до 11 секунд). Такое снижение производительности делает использование таких идентификаторов в традиционных документоориентированных программах учета, мягко говоря, не очень привлекательным.

Такой-же тест проводился с проектом Access’2002 и сервером MS SQL’2000 Desktop Edition (MSDE). GUID’ы получались с помощью функции NewID(), а идентификаторы целого типа – с помощью Identity с единичным инкрементом.

Результат получился совершенно другой: в обоих случаях запрос выполнялся около двух секунд и разница субъективно не была заметна. Это, скорее всего, позволяет в данном случае не учитывать критерий быстродействия при выборе типа идентификатора.

Однако, есть ещё несколько факторов, существенных при решении такого вопроса. Главный из них, на мой взгляд, – насколько хорошо клиентская система (MS Access в нашем случае) поддерживает этот тип данных.

Расшифровка представления битой ссылки. как перевернуть гуид. uuid to guid и обратно…

Создание уникального идентификатора (guid) – useful developers tools

Структура guid

Структуру GUID Microsoft описывает следующим образом (HOWTO: Use GUIDs w/ Access, SQL 6.5 and SQL 7):

    typedef struct _GUID

    {

        unsigned long   Data1;

        unsigned short  Data2;

        unsigned short  Data3;

        unsigned char   Data4[8];

    } GUID;

А визуальное представление, которое ещё называется каноническим видом, вот так (BOL):

{6F9619FF-8B86-D011-B42D-00C04FC964FF}

Налицо явное несоответствие: 4 элемента в определении типа и 5 частей в строке. Это можно понять, если внимательно рассмотреть самую правую часть строки. Она как раз и представляет собой шестибайтовый MAC-адрес сетевой карты. Следующие два байта тоже как-то связаны с оборудованием, и, вполне возможно, способствуют решению проблемы возможного совпадения адресов в некоторых сетевых платах.

Левая половина кода, несмотря на разбиение на три части, может быть интерпретирована как метка времени. В примере (для Access’97) есть функция (найдена в конференции MAUG), которая извлекает из неё момент начала текущего сеанса работы. То, что она делает, выглядит как шаманство, однако для GUID’ов, сгенерированных Access’ом и MSSQL Server’ом, даёт вполне верный результат.