есть у меня необходимость сделать регистр с измерением "уникальный идентификатор", штатно это сделать 1с не дает (нет такого типа в списке выбора).

можно сделать определяемый тип с типом "уникальный идентификатор" и уже в измерение закинуть этот определяемый тип.

или можно сделать по аналогии с типовым регистром "соответствиеОбъектовИнформационныхБаз" где вместо УИ лежит строка[36]

теперь вопросы -
1. чем обусловлено что 1с не дает в измерениях выбирать такой тип (кроме контроля ссылочной целостно)?
2. какой вариант лучше и чем они плохи про то, что индексирование строковых параметров отжирает больше индекса чем индексирование ссылки я знаю, еще какие заморочки есть?

Сделай строку и пихай туда XMLСтрока(ТвойУИД)

(0) УникальныйИдентификатор в реквизите будете средствами 1С делать?

(2) уникальный идентификатор буду копировать из документа, он есть в реквизите ТЧ документа

(0)
1. Я думаю, 1С старается не поощрять подобное, т.к. если совсем уж произвольные guid-ы пихать, то это вступит в непростые отношения с кластерным индексом итогов. Хотя, строковые измерения тоже не рекомендуется делать в РН.
2. Для РН - думаю, без разницы, оба варианта так себе, но я бы сделал строковый реквизит, дабы не нарваться не неизвестные мне грабли.

Не эксперт, не обессудьте. )

решил попробовать вариант 2 - 1с не дает сохранить изменения, пишет тип не верный, по этому только вариант 1 (строка)

практическую часть вопроса можно считать снятым, остается теоретическая:

почему 1с это запрещает?

В типовых регистрах предназначенных для обмена используется тип строка

(5) Потому что грохнут ссылку, из которой вы получили ваш УИД, и этот УИД превратится в тыкву.

(5) Есть вариант: создать простой справочник и использовать его.
(7) бред

(7) так сейчас аналогично происходит с любым измерением ссылочного типа, если сам элемент удалят..Просто будет битая ссылка.
Аналогично, был бы битый гуид.

Просто товарищам с селезнёвки нужно было лет 10 назад добавить в запросе получения гуида для реквизитов ссылочного типа, только и всего лишь. Это намного бы упростило делать обмены со сторонними ресурсами.

(9) "битый гуид" - это как?

Всё даёт. У меня Регистр сведений такой сделан - оч.удобно.

Тпи пятый сверху - Уникальный идентификатор. 8,3,10

(12) У ТС скорее всего РН, там нельзя.

РС - дает, РН - не дает.

(13) РС - дает
РН (подчиненный регистратору) - нет

Регистр накопления предполагает итоги и упорядочивание.
Вопрос упорядочивая по гуид можно долго обсуждать,и,видимо,на селезневке все еще обсуждают.
И получается 72 байта вместо 16.

(17) Что за 72 байта? Вместо каких 16-ти?

(17) чем ссылка отличается от гуида?

(18) он имеет в виду размер в сборном индексе

(18) GUID в виде строки UTF-16.

(20) Гуид в виде строки недавно был 36 знаков:
00000000(8)-0000(12)-0000(16)-0000(20)-000000000000(32+4(-))
Откуда 72 ?

Ссылка,это еще и тип обьекта,кроме гуида,то,что он в регист не пишется,если обьект один,еще не значит,что его нет.
72 байта,это 36 символов по 2 байта в индекс по строке,если пишем представление гуида.

а разумнее было бы тип Binary до ума довести,но 1с не скоро созреет.

(0) Только строка, фиксированная 36 символов.

(21) 36*2 (UTF) = 72

(24) 36*3 (ХЗЧ) = 108

Речь-то о чём? Что за UTF, почему именно про него? Что у него не так со строками?

(22) 36 символов по 2 байти в индекс? Индекс в два раза больше данных? Ээээ...

(25) UTF-8 - двухбайтная строка...
@в самом распространённом UTF-8 символ может кодироваться последовательностью от 1 до 4 байт.@

Но это уже на совести (17)

(27) 1С данные хранит в УТФ-8 ?

(28) Удивишься...

(0) Зачем?

Я один не понимаю проблему автора?

https://yadi.sk/i/BLr5fm7Ije2CnA

А, все понял, РН.

(0) индексирование строковых параметров отжирает больше индекса чем индексирование ссылки я знаю

с чего бы это. гуид такая-же строка, с определенной длиной. ну если только с ограниченным набором символов.

(34) Это магия.

(35) я в магию не верю

(0) Преобразуй GUID в число.
17 байт данных на numeric хватит всем.

(37) Ради экономии 2-3% от максимальной длины составного индекса?

(38) Нет. Там экономия гораздо больше.

(4)"1. Я думаю, 1С старается не поощрять подобное, т.к. если совсем уж произвольные guid-ы пихать, то это вступит в непростые отношения с кластерным индексом итогов. Хотя, строковые измерения тоже не рекомендуется делать в РН."
Не пиши ерудны.
1С сама так делает или про гуиды, конвертированные в binary(16) и помещенные во все кластерные индексы мы вдруг забыли?
Строка - зло, но если только переменной длины, т.к. может привести к превышению длины строки индекса. Если же она фиксирована, то нет препятствий.

(40) Еще одна дичь.

(0) Какая проблема использовать строку 36 символов?

(42)
- Хранить эту строку в виде лишний 64 байт (если вырезать дефисы).

- Сортировать эту строку по правилам языка, а не по физическому значению, что на порядки дольше.

(41) У автора поста (4) - да, дичь.

(43) - не надо ничего вырезать, храни как есть в строке и все. что тебе места жалко что-ли, в каком веке живешь?

- не надо сортировать идентификатор

(43) SQL справится с твоей 36-символьной строкой, не переживай

(45) Идентификатор будет сортироваться при построении индекса.

(46) Я не переживаю. Я просто рассчитываю, что не пересекусь с вашими разработками.

(45) "что тебе места жалко что-ли, в каком веке живешь? "

А потом появляются конфигурации, к примеру, хранящие акцизные марки в виде строки в 150 символов в измерении РС, по позиции регистратора, которых может быть несколько типов.
Посмотрим, как это взлетит на отгрузке, когда всё завертеться.

(47) да пускай сортируется

(48) ой ой ой, какие мы крутые.

Мушку спили

(47) Я не думаю что у тебя идет учет столкновения элементарных частиц в коллайдере.
MS SQL нормально пережует твои несчастные 72 байта в ключе.

Если уж сильно хочется сделать по феншую, что бы потом хвастаться, то перегони свою 36-строку в 4 байтовое число (как это делает платформа) и будет тебе счастье.

А потом эти ленивые жопки спрашивают "че у нас евро такой дорогой". А сами же делают свой работу наотъебись.

(49) Сколько гигабайт занимает твоя sql-таблица к который ты хочешь прикрутить guid?
Меньше 100 Гб?

(52) хосподя, да черт с тобой, можешь любоваться на себя в зеркале, не забудь нимб протереть, академический наш

(53) Речь не идет о размерах хранения, на это всем похрен.
Речь идет об обновлении итогов регистра накопления, в которых и скрыто 80% времени проведения документа.

(55) В сабже не было речи о том что guid над прикрутить в рег.нак который двигается проведением.
Это совсем другой вопрос.
Тогда это хреновая идея вообще.

Речь шла,как я понял, про синхронизацию объектов, для этого нужный такие ключи.

Сделай определяемый тип. это же проще, чем потом конвертировать ГУИД туда-обратно.

(56) надеюсь, эти ключи будут в реквизитах, а не в измерениях.

Ну или так: если нужно запросом получать гуиды элементов справочника из измерений - добавить в справочник реквизит GUID, заполнять при первой записи справочника из ссылки. А в запросе получать гуиды через точку. Тогда не нужно ломать регистры.

(56) А существуют РН, которые двигаются не проведением документов?

(60) Не было речи об РН

(60) конечно. корректировка записей регистров, например. Записывает в регистр без проведения.

(60) это практически вопрос из профа)

(62) И что же, интересно, пишется в регистратор?

(64) корректировка записей...