GUID
При решении задачи консолидации данных всегда возникает проблема создания уникальных идентификаторов объединяемых записей. Существует много вариантов выбора типа и способа формирования таких идентификаторов, но самый простой - применение GUID.
Что такое 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
Структуру 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'ом, даёт вполне верный результат.
Практическое использование 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 в нашем случае) поддерживает этот тип данных.
GUID и Access'97
Всё написанное ниже относится к русской версии с установленным пакетом обновления 2 (SR-2) и типу данных "Числовой" или "Счетчик" с размером поля "код репликации" для таблиц JET. Хотя, присоединённые таблицы MS SQL Server ведут себя аналогично.
Создаётся впечатление, что 97-й Access не был изначально рассчитан на активное использование этого типа данных. Он описывается как массив байтов (vbByte + vbArray), то есть отдельного типа не предусмотрено. Различные варианты получения содержимого элементов управления и полей наборов записей дают самые разнообразные результаты:
| В форме (txtID - поле формы, ID - поле набора записей формы, не связанное с каким-либо элементом управления) |
| Me!ID: |
аК=Vg/~ъR^щW5*Ф[ (строка из 16 символов) |
| Me.txtID.Value: |
???????? (байтовый массив, который выводится в окне отладки скорее всего как строка Unicode) |
| Me.txtID.Text: |
{6F9619FF-8B86-D011-B42D-00C04FC964FF} (строка, что мы видим на экране) |
| В наборе записей |
| RS!ID: |
{guid {6F9619FF-8B86-D011-B42D-00C04FC964FF}} (строка, аналогичная результату применения функции StringFromGuid) | |
Такое многообразие форм напоминает природу тропического леса и так же грозит массой сюрпризов. Однако постепенно всё это запоминается и начинает давать предсказуемые результаты.
Для взаимного преобразования представлений служит пара функций: 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
|
