[ главная ]   [ рейтинг статей ]   [ справочник радиолюбителя ]   [ новости мира ИТ ]



Ответов: 0
25-02-12 07:01







   Web - программирование
PHP


ASP






XML



CSS

SSI





   Программирование под ОС











   Web - технологии








   Базы Данных









   Графика






Данные




Базы Данных / Разное /

Что такое 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

Источник: ssy.mccinet.ru




Комментарии

 Ваш комментарий к данному материалу будет интересен нам и нашим читателям!



Последние статьи: Базы Данных / Разное /

Разработка запросов
08-03-2010   

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

Кол. просмотров: общее - 3701 сегодня - 1

Параметрическое определение порядка сортировки данных
08-03-2010   

В различных сетевых форумах часто обсуждается вопрос: как получить отсортированные результаты выполнения запроса, передавая хранимой процедуре некоторый параметр? Я собрал несколько решений этой задачи, предложенных талантливыми программистами. Основная часть идей, изложенных в этой статье... подробнее

Кол. просмотров: общее - 3769 сегодня - 1

Delete from mytable; Commit:.. или Восстановление данных в СУБД Interbase
08-03-2010   

Данная статья написана на основе статей: The Interbase On - Disk Structure by Ann Harrison ; Structure of a Data Page by Paul Beach, а так же включает в себя мой горький опыт в удалении важных данных, а потом в их успешном восстановлении. Я никоим образом не собираюсь нарушать права ни выше перечисленных авторов, ни компаний, чьи зарегистрированные торговые знаки перечисленные в данной статье... подробнее

Кол. просмотров: общее - 3821 сегодня - 0

Часто задаваемые вопросы по базам данных
08-03-2010   

СУБД — Система Управления Базами Данных (dbms — database management system). Программа, либо комплекс программ, предназначенных для полнофункциональной работы с данными. Как правило, включает в себя инструменты для создания и изменения структуры хранения наборов данных... подробнее

Кол. просмотров: общее - 4253 сегодня - 0

Временные таблицы в sql server. Так ли необходимы временные таблицы?
07-03-2010   

Временные таблицы всегда прекрасно помогали разработчикам. Раньше, когда я использовал access, я обычно создавал временные таблицы, которые удалял после решения задачи. При использовании sql server решить задачу можно гораздо проще. Не так ли?... подробнее

Кол. просмотров: общее - 3768 сегодня - 1



  WWW.COMPROG.RU - 2009-2012 | Designed and Powered by Zaipov Renat | Projects