Готові рішення для 1с підприємства

Що таке GUID або унікальний ідентифікатор об'єкта?
GUID (Globally Unique Identifier) ​​- статичний унікальний 128-бітний ідентифікатор. Його головна особливість - унікальність, яка дозволяє створювати розширювані сервіси і додатки без побоювання конфліктів, викликаних збігом ідентифікаторів. Хоча унікальність кожного окремого GUID не гарантовано, загальна кількість унікальних ключів настільки велике (2128 або 3,4028? 1038), що ймовірність того, що в світі будуть незалежно згенеровані два співпадаючих ключа, вкрай мала.
GUID складається з чотирьох частин розділених символом тире і містять в сумі 32 символу, які є шістнадцятковим поданням 16 байт (128 біт). Тобто два символи в GUID (октет) - це один байт в шістнадцятковому вигляді. Приклад GUID: b0d4ce5d-2757-4699-948c-cfa72ba94f86
[1]

Чому використовується guid, а не простий auto-increment (indentity)?
Для використання Гуїдо є 2 причини:
- хочемо щоб база даних або який-небудь інший сервер (кластер) не мав централізованого управління генерацією ключів
- потрібно позбутися проблеми створення однакового ідентифікатора на різних робочих серверах
Такі проблеми зазвичай виникають в розподіленої середовищі виконання, а кластер серверів позиціонується як розподілений і бажано повністю уникнути єдиної точки видачі унікальних ключів.
Якщо ваша система не має таких вимог, вам не потрібен UUID.
[1] [2]

У чому різниця між uuid і guid?
UUID це термін з стандарту rfc4122, який опублікує всесвітня організація стандартизації eitf.
Грубо кажучи GUID це те що вийшло на практиці у Microsoft. Теорія відрізняється від практики так само, як і XML з HTML.
[1] [2]

З чого складається guid?
Визначається типом:
- Random: Just use the system's random-number generator to create a 128-bit number.
- Time-based: Create a GUID based on the current time.
- Hardware-based: Make a GUID with certain portions based on hardware features, such as the MAC address of a network card.
- Content-based (MD5 or SHA-1 hash of data): Create a GUID based on a hash of the file contents. Files with the same contents will get the same GUID.
[1]

Як визначити версію GUID?
Версія Гуїдо визначається в старшому байті 7 октету.
b0: d4: ce: 5d-27: 57-4 6: 99-94: 8c-cf: a7: 2b: a9: 4f: 86
[1]

Чому не можна впорядкувати за посиланням, якщо в ній міститься дата створення?
Як вже було описано, guid спочатку був придуманий для розподілених систем, в яких ПРОБЛЕМА унікальний ідентифікатор вирішена повним відмовою від автоінкремента на користь ВИПАДКОВИХ чисел і спеціальних технік. GUIDи випадкові і неповторяемость за визначенням і в цьому його перевага і недолік. Наприклад, в зумовлених елементах і довільних ідентифікатори використовується Random GUIDs (Version 4). В "типізованих" же Time-Based GUIDs (Version 1).

Використовуються різні стандарти?
Так, але коли індексам БД доводиться працювати з випадковими значеннями ключів (див. B-Tree Insertion) виникають проблеми.
[1] [2]

Тобто для посилань може створюватися Random GUID?
Тільки для визначених елементів і вручну створених Гуїдо.

І все таки?
Random UUIDs викликають деградацію операцій вставки. У таких Гуїдо індекси виходять погано кластерізовани, дерево пошуку максимально широке. Для обходу цього недоліку був придуманий COMB Guid - Combined Guid for the combination of a timestamp. Тому коли використовуються Time-Based GUIDs для первинних ключів, вони виходять більш згрупованими, але ніяк не послідовними. "Механізм генерації посилань забезпечує тільки їх унікальність. Зростаюча послідовність при їх генерації не забезпечується." (C) БГ
[1]

Але у Гуїдо є ж послідовність? Щось там про момент часу?
Та скільки можна? Немає у Гуїдо послідовності! Хто перший запросив - тому і видається пул. А коли вже сеанс його вичерпає - залежить від нього самого. Читаємо докладніше про експеримент з МоментомВремені.
//1c.ruboard.ru/public/84177/

Чому частини часу йдуть "задом-наперед"?
"Так склалось" ;)
Наприклад бо guid'и з'явилися задовго до того, як до них дісталися руки ietf і баз даних.
Чи тому що платформа написана на C, а не на Java, а як ми знаємо з асемблера архітектура x86 має little-endian byte order.
Або, як каже вікіпедія, використовувалося 2 варіанти: для п ередачі по мережі "on-wire" "network" (big-endian) byte order, а для зберігання "native" (little-endian) byte order.
У будь-якому випадку я не знаю як там було і можна тільки здогадуватися.
[1] [2] [3] [4]

Чому не можна використовувати час з GUID?
По-перше, Гуїдо може бути випадковим, а не підстава на часі.
По-друге, Гуїдо видаються пулом по 32 штуки для кожного сеансу.
По-третє, Гуїдо випадковий по своєму стандарту і час в ньому це лише спосіб згрупувати первинні ключі для зменшення ширини В-дерева і прискорення операцій вставки в кластерний індекс!
[1] [2] [3]

Чому використовується "перевернутий" формат UUID всередині 1с?
<Объект не найден> (26: 80f408002771598b11e7a3f0a3a64c3b)
Не знаю. Знаю тільки що перша цифра відповідає імені таблиці в sql: Reference26 -> ВідиНоменклатури

Готові рішення для 1с підприємства

[1]

7 хвилин, частина mid через 1 рік, частина hi самі уявляєте.

Version - старші 4 біти в сьомому октеті, містять тип Гуїдо.
0x0001 1 time-based version
0x0010 2 DCE Security version (POSIX UIDs)
0x0011 3 name-based version (MD5 hashing)
0x0100 4 randomly generated version
0x0101 5 name-based version (SHA-1 hashing)


Clock Sequence - використовується щоб уникнути появи дублікатів, коли стрілки годинників переводяться назад чи змінюється ідентифікатор вузла. Якщо попереднє значення лічильника відомо - то збільшується на одиницю, інакше береться випадкове число.

Приклади? Є їх у мене.
Ми ж "програмісти", накодо функції:

Перевіримо посилання звичайного документа:

Перевіримо посилання, сформовану вручну:

Перевіримо роботу лічильника "унікальності":

Сподіваюся, тепер думка про те, щоб "упорядкувати за посиланням", я з вас витрусив остаточно.

Схожі статті