Вход | Регистрация
 

Как формируется GUID? (Уникальность его в пределах разных баз)

Как формируется GUID? (Уникальность его в пределах разных баз)
Я
   Mendel_UA
 
30.10.10 - 18:21
GUID сериализуется при обмене как довольно длинной строкой, но все-таки существуют опасения, как бы при обмене двух и более независимых баз не возникла ситуация когда в разных базах существуют РАЗНЫЕ элементы с одинаковым GUID.
В данный момент рассматриваю ситуацию в которой одна база обменивается с 29 других баз которые никак между собой не связаны (в смысле это не РИБ и никто не является ни для кого родительским узлом).
   est
 
1 - 30.10.10 - 18:23
опасения имеют основания
   Aleksey_3
 
2 - 30.10.10 - 19:40
Опасность есть, но главное чтобы гуид был уникален в разрезе типа и вида. Т.е. если элемент справочника номенклатура и контрагент имеют одинаковый гуид - то ничего страшного в этом нет
   Aleksey_3
 
3 - 30.10.10 - 19:40
   sda553
 
4 - 30.10.10 - 20:42
Говорят что и метеорит может на голову упасть. На практике его неуникальнность за всю мою рабочую деятельность не встречалась.

Если у вас возникли проблемы с обменом, то для программиста это слабая отмазка, ищите проблему в другом месте
   sda553
 
5 - 30.10.10 - 20:45
(0) Скорее всего работает обмен, который синхронизирует по ГУИД и еще какой то механизм загрузки данных (загрузка из 7.7 например) с синхронизацией по коду/наименованию или еще чему то. Вот и возникает такой конфликт, обмен создает элемент и поначалу они одинаковые с одинаковым ГУИД, потом какая то загрузка по коду переписывает эти элементы на свои другие, получается что ГУИД один а элементы разные
   pectopatop
 
6 - 30.10.10 - 21:27
Вероятность очень мала, настолько что ей можно пренебречь.
В алгоритме формирования ГУИДа участвуют в том числе и MAC-адрес компа, и текущее сист.время, и счетчик тактов процессора. Выпадающие ГУИДы РАВНОМЕРНО заполняют пространство параметров.
   Mendel_UA
 
7 - 30.10.10 - 22:47
(4) Проблем пока нет, стараюсь такие проблемы оставлять на этапе проектирования :)
В данный момент это 29 независимых РИБ из которых в главке информацию достают раздельно, распечатывают/сохраняют, и потом сбивают вручную в единые отчеты.
Но каждая из этих 29 баз сама по себе не маленькая.
У меня например это 65 узлов, все в ФАЙЛОВОМ режиме :)
На некоторых узлах по 15 человек одновременно.
Конечно у меня самая большая база из этих 29, но тем не менее утешение это слабое.
Часть проблем я уже решил, (к примеру автообмен у меня значительно интелектуальнее типового), часть примерно знаю как решать, но пока не имею полномочий... но наверняка есть и такие о которых я еще не знаю :) Вот их бы хотелось сократить до минимума...
ПЫСЫ: Я знаю, что файловый режим да еще и на 8.0 это мазохизм в моей ситуации, но пока еще этот вопрос не в моей компетенции... :)
   PVasili
 
8 - 31.10.10 - 00:45
топик стартер: оцените степень числа в GUID?
Посчитайте вероятность от: 340 282 366 920 938 463 463 374 607 431 768 211 455 возможных вариантов.
Надеюсь вопрос отпадет сам собой :)
   Aleksey_3
 
9 - 31.10.10 - 00:58
(8) Все бы хорошо, если не 1С
"GUID 1С формирует не по правилам Microsoft, а инкрементно.
В начале сеанса формируется стартовый GUID, r примеру
6F9619FF-8B86-D011-B42D-00CF4FC964F0 "
   PVasili
 
10 - 31.10.10 - 01:11
GUID и в Африке GUID. 1С тут не при чем.
Скорее всего указанные используется для чего-то другого, а не для данных.
Посмотрите сколько в реестре Win GUID ключей. 38 степень покроет всё, что может вам в голову придуматься в любых количествах :)
   Mendel_UA
 
11 - 31.10.10 - 02:33
(10) именно причем. сделал четыре новых документа подряд, получил следующие номера:
b6dc1ccc-e472-11df-922d-001e33069798
b6dc1ccd-e472-11df-922d-001e33069798
b6dc1cce-e472-11df-922d-001e33069798
b6dc1ccf-e472-11df-922d-001e33069798
Хотя если честно это не сильно влияет на надежность метода, но факт остается фактом.
Ну и расчет "Посмотрите сколько в реестре Win GUID ключей" несколько неверен, ибо количество возможных комбинаций и вероятность коллизий это совсем различные понятия. Для краха данных достаточно одной малюсенькой коллизии :)

Однако это все теория. На практике вероятность коллизии все равно очень мала, и в 1С без того хватает причин для краха данных :) Хотя если бы 1С предусмотрела в обмене флаг "новый/измененный", то проблемы бы совсем не стоило бояться -просто при создании объекта который уже существует, надо было бы вызывать исключение и звать админа искать проблему.

ПЫСЫ: Кстати реально существует возможность образования разных данных с одинаковыми идентификаторами. При не очень толковых выгрузках/загрузках с помощью устаревших обработок можно поймать такие глюки. У меня такие реально есть в базе.
Пока не придумал как лечить. Жду конца года, когда буду делать "Матрица перезагрузка".
   Собеседник
 
12 - 31.10.10 - 08:27
(0)
простой пример "неуникальности" GUID :
28 база делалась ...когда-то давно... методом копирования 27-ой :). Удалили "лишние" и переименования "нужные" справочники, удалили все документы.
вот тебе и "счастье"
   Живой Ископаемый
13 - 31.10.10 - 15:05
проблема не стоит выеденного ийца.  потому что если вдруг даже что-то такое случится, то во-первых - при загрузке в центр, где уже есть объект с таким уидом произойдет ошибка - и ты сразу эту проблему локализуешь (а если уид назначится объекту другого типа/вида - то вообще не проблема)
во-вторых понятно что в этом случае делать, как исправлять.
Поэтому тема не относится к разделу в8 а относится к разделу "как страшно жить" или "посоветуйте надежного и недорого психолога".
   Aleksey_3
 
14 - 31.10.10 - 16:26
Ну ошибку он не получит, у него просто обновятся данные
   Живой Ископаемый
15 - 31.10.10 - 16:39
Если у него используется дата запрета редактирования, и документ с таким же УИДом был в прошлом, то по крайней мере получит сообщение что редактирование данных того периода запрещено. Если конечно не настолько интеллектуализировал обмен, что он не будет проверять дату запрета.
   Mendel_UA
 
16 - 31.10.10 - 21:01
(15) "если" это плохое слово :)
А если не используется, тогда что? :)
А если проблемы со справочником, тогда дата запрета сильно поможет? А если перезаписываемый документ недавно создан и его еще можно изменять?

Ну а вообще вопрос конечно не особо критичный для большинства приложений. Ну потерялся справочник-документ, ну бывает...
раз в десять лет.
   Sammo
 
17 - 01.11.10 - 06:36
+ рекомендую учесть возможность ввода гуида руками
   МаленькийВопросик
 
18 - 01.11.10 - 06:37
при подобных обменах обычно используются префиксы документов.
   Mendel_UA
 
19 - 01.11.10 - 10:02
(18)Префиксы к номеру относятся - это для людей. А сам 1С пользуется GUID. У GUID префиксов нет.
   skunk
 
20 - 01.11.10 - 10:06
сегодня попробовал универсальным обменом выгрузить два элемента справочника пользователей ... лень было руками в другой базе настраивать ... получил уникальность гуида
   Живой Ископаемый
21 - 01.11.10 - 10:43
так я и думал... короче, вот вам рецепт.. он не вылечит паранойю, но существенно ее купирует.
Заводите независимый РС с единственным измерением типа строка с длиной достаточной чтобы принять строку гуида. При начале работы системы берете какой-нить справочник и получеате ссылку нового для него
получаете строку типа
b6dc1ccc-e472-11df-922d-001e33069798

заменяете два последних символа в первой группе на "_"
получаете
"b6dc1c__-e472-11df-922d-001e33069798" ищите запись в этом РС подобную последней строке. Если находите - завершаете работу системы

Само собой РС должен ходить по всем 29 базам.
   Живой Ископаемый
22 - 01.11.10 - 11:10
Ну тем самым мы предполагаем что в рамках одного сеанса может быть заведено 256 объектов :)


Список тем форума
 
ВНИМАНИЕ! Если вы потеряли окно ввода сообщения, нажмите Ctrl-F5 или Ctrl-R или кнопку "Обновить" в браузере.
Ветка сдана в архив. Добавление сообщений невозможно.
Но вы можете создать новую ветку и вам обязательно ответят!
Каждый час на Волшебном форуме бывает более 2000 человек.