При условии, что между этими базами не было обменов, т.е. эти ИД появились в базе просто при вводе пользователем независимо новых объектов в базах... Или все-таки вероятность стремится к нулю?

вероятность есть

*всегда

Просто ваяю перенос между уже работающими базами, соответственно встал вопрос можно или не желательно синхронизировать по внутренним идентификаторам...

(3) не можно, а нужно. вероятность встретить одинаковый пренебрежительно мала

(3)Ситуацию, когда внутренний ИД повторяется, тоже можно обработать. Но это скорее будет обработка "на всякий случай". Если синхронизировать по коду и наименованию, то геморроя будет гораздо больше и обрабатывать ошибки при таком подходе придется гарантированно.

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

(0) практически невозможно, за 3 года в 5 базах не возникло ни разу )

(6) речь про uid-ы

(8) А я про что?

УИД живут в таблицы. Причем для каждого документа/справочника свой уид. Нельзя без вида по УИДу найти объект (ну только если перебором всех таблиц)

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

(11) в уид в восьмерке включен вид метаданных, уид из 2х частей состоит.

(12) внутренний ИД не содержит вида

можно даже в одной и той же базе найти.
К примеру, в одной из типовых версикй типового обмена между УТ11 и БП20 из одного документа (кажется ПТУ) делалось 2: ПТУ и допрасходы. Так вот у обоих одинаковый идентификатор. Что приводило к ошибке при заполнении книги покупок

(14) Книга покупок по внутренним кодам работает?

Для составных полей там по любому вид будет

Почитай v8: Как из плана обмена вытащить GUID внешнего объекта
В двух разных базах ГУИДы могут быть одинаковыми тогда и только тогда, когда объект перенесем из одной базы в другую. Или сама получена копированием (частный случай массового переноса объектов)

(0) Вероятность что у тебя образуется вагина от мутаций куда больше, чем в id попасть

Маловероятно.
Но могли вносить руками

про какой объект в частности говоришь ?

(11) Бред. Даже обосновывать не хочется.

Что именно бред, что не может быть номенклатуры и контрагента с одинаковым внутренним кодом?

или например документа поступления и с таким же кодом документ реализация?

Да, если это не сделано руками.

(24) Стоп. Я лишь уточнил сабж. Т.е. берем разные 2 базы. База А и база Б, которые жили своей жизнью. Далее решили настроить обмен по внутренним идентификатору между базами. Соответственно был вопрос могут ли эти коду повторятся. Я лишь уточнил, что для обмена не важно что код номенклатуры в базе А точно такой же как и код у контрагента в базе Б (мы же можем допустить что 2 разных вида справочника в разных базах по какой то причине получили одинаковый код?) Для обмена и для 1С это все равно будут разные элементы, потому что идентификация идет по паре вид + уникальный идентификатор, а не только по внутренним идентификатору

Ты же пишешь что это бред, и типа даже объяснять не буду

P.S. для буквоедов в тексте под кодом имеется ввиду внутренний уникальный идентификатор, который без вида

(25) Съехал.

Из (11) >> Отсюда вывод, уид уникальный должен быть в рамках вида, а не всей базы

Это бред.

(26) А по твоему для идентификации объекта внутренний уникальный идентификатор должен быть уникальный для всей базы?

При условии что этот идентификатор не содержит вид?

Или мы о разных вещах говорим, или кто-то заблуждается

(29) я говорю об УникальномИндетификатре, а ты говоришь о Ссылке. И полностью с тобой согласен в части поиска объектов, но не в части (повторюсь) >> Отсюда вывод, уид уникальный ДОЛЖЕН БЫТЬ в рамках вида, а не всей базы

+(29) он ДОЛЖЕН БЫТЬ уникальным везде. Если не уникален - кто то накосячил.

(30) Что есть УникальномИндетификатре?

Я почему справшиваю, запустил у себя в базе (в БП)

справочники.СтатьиЗатрат.СписаниеНДСНаРасходы.УникальныйИдентификатор()

вернуло
6a99979c-b822-417f-bc35-2df9f6d0af10

И где тут вид?

тоже самое

КлючУникальности = Новый УникальныйИдентификатор;

Вернет тоже 32 символа (если черточек не считать), без привязки к виду. Т.е. в терминах 1С УникальныйИдентификатор не привязан к виду, и программа вполне себя хорошо чувствует, когда УникальныйИдентификатор одинаковый у номенклатуры и контрагента

при этом не зная вида, кроме как перебором видов, нельзя найти что это за элемент с 6a99979c-b822-417f-bc35-2df9f6d0af10

(34) Давеча писал - "Нет не решаемых задач - есть не рациональные решения".

(35) А по теме?

(0) Вероятность совпадения ГУИДов в двух независимых базах есть и она больше нуля. ИМХО, этого уже достаточно, чтобы НЕ использовать ГУИД как единственный ключ для сопоставления объектов в двух независимых базах..
Если особо интересно, вероятность эту можно посчитать.. грубо 16^32 вариантов ГУИДов, количество объектов в БД тоже примерно прикинуть можно..
Из практики, на моей прошлой работе был настроен обмен: не по ГУИДам (32 байта), а по части ГУИДа (то-ли 28 байт, то-ли 30 уже точно не помню). Пару лет все было нормально. А потом начались совпадения.

Изначально GUID делался как глобальный уникальный идентификатор. То есть для его генерации используются данные компьютера, MAC-адрес сетевой карты, время генерации и другие параметры, которые должны обеспечить его уникальность - так в теории.
Но на практике оказывается, что все данные могут совпадать (а с учётом использования нескольких ядер в процессорах - то даже на одной машине).
Кроме того - значительное число "верующих в уникальность GUID" привело к тому, что его стали слишком часто использовать - а совпадений тем больше, чем большее число раз он создаётся.

(37),(38) - может представить из жизни пример совпавших ГУИДов, созданных 1С?
(37) - "настоящих", полноразмерных

(37) Естественно не единсвенный, сначала по Гуиду, потом по полям поиска, хотя было бы здорово, если бы в КД была возможность сделать обратную последовательность - сначала по полям поиска, а потом по Гуидам...