Как лучше хранить ссылки на элементы справочников из других баз идентичной конфигурации? Есть три варианта Строка(36), УникальныйИдентификатор, в виде "битых" ссылок. Какой вариант предпочтительней с точки зрения производительности запросов с участием  этих полей, что лучше индексируется?

(0) сначала скажи зачем?

если нужно будет его представление, то лучше и хранить как идентичный справочник

(0) Ссылка - это кроме ИД, еще и тип. Которого в другой базе элементарно может и не быть.

(2) "идентичной конфигурации"

(0)о че бы объекты не хранить?

ЗначениеВСтрокуВнутр(), ЗначениеИзСтрокиВнутр() - использую при обмене через COM соединение.

Храни УникальныйИдентификатор

(1) Да, представление нужно будет

(7) тогда прочти (1) полностью

сами элементы справочника и храни... что мешает?

(8) Из-за представления создавать идентичные элементы справочника? Нужно только ссылка+представление

(10) смотри тогда (9) раз непонятно

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

(12) а скорость чтения?
большие это насколько?

ЗначениеXML

или (6)

(13) скорость меньше, но это не критично. К примеру насколько для Вас критична скорость загрузки страниц при работе в интернете? Никто же не тащит всю информации на ваш компьютер. Или к примеру работа в веб-клиенте 1С

(16) ты помнишь как миста тормозила?

(6) А как хранится одинэсовский УникальныйИдентификатор в базе данных?

(17) нет, не помню)

(18) Что конкретно тебя интересует?

(20) Тип значения в БД SQL.. на индексирование же влияет тип данных.

(21) binary(16)
Так же, как у ссылки. Все норм.

(21) бинарный тип

ну т е для индексирования это лучше чем Строка(36)?

Да

Спасибо, тогда остановлюсь на таком варианте. Сначала сделал строковый тип, но возникли сомнения, решил уточнить)

искать тут оптимальный тип... не в этом проблема будет, а в постоянном дёрганье веб-сервиса на получение данных по этому элементу. То, что ты мог запросами узнать у себя в "общей" базе - придётся дёргать веб-сервис

(27) вроде как скоро обещают REST сделать, он вроде производительней чем SOAP

(28) если бы да кабы... Везде где видел подобные реализации "общих справочников" аля НСИ - хранят спокойно сами элементы, обмениваются или по планам обмена, или просто сериализуют элемент в файл и кидают спокойненько в другую базу. Более универсально и надёжно это вот, вдруг потом понадобится реально эта информация? Делать дак на века...

Такс, первый глюк с УникальнымИдентификаторм. Создаю ТЗ с типом колонки УникальныйИдентификатор, помещаю ТЗ во временную таблицу - "тип не может быть выбран в запросе".

ЗначениеВСтрокуВнутр.
Если правда идентичные конфы конечно

(31) ЗначениеВСтрокуВнутр это строка, причем длиннее 36 символов, если уж хранить в строковом виде тогда, тогда лучше Строка(УникальныйИдентификатор)

ТЗ точно типизирована?

(32)А УникальныйИдентификатор потом пербором по всем таблицам будешь выискивать?

ТЗ = Новый ТаблицаЗначений;
    ТЗ.Колонки.Добавить("УИД", Новый ОписаниеТипов("УникальныйИдентификатор"));

Я бы в качестве строки ГУИД хранил.
XMLСтрока/XMLЗначение кстати быстрее всего отрабатывают

(34) Нет, зачем?
(35) Да, так и есть

в БСП подсистема обмен данными - как строку хранят (РС СоответствияОбъектовИнформационныхБаз)

(38) как строку не очень хорошо, но возможно придется. Еще вариант хранить "битые" ссылки

ТЗ = Новый ТаблицаЗначений;
    ТЗ.Колонки.Добавить("УИД", Новый ОписаниеТипов("УникальныйИдентификатор"));
    
    НС = ТЗ.Добавить();
    Нс.УИД = Новый УникальныйИдентификатор;
    
    Запрос = Новый Запрос("ВЫБРАТЬ
    |    времТЗ.УИД
    |ПОМЕСТИТЬ времТЗ
    |ИЗ
    |    &времТЗ КАК времТЗ
    |;
    |
    |////////////////////////////////////////////////////////////////////////////////
    |ВЫБРАТЬ
    |    времТЗ.УИД
    |ИЗ
    |    времТЗ КАК времТЗ");
    
    Запрос.УстановитьПараметр("времТЗ", ТЗ);
    
    Запрос.Выполнить().Выбрать();

{Форма.Форма(25)}: Ошибка при вызове метода контекста (Выполнить): {(2, 2)}: Тип не может быть выбран в запросе
<<?>>времТЗ.УИД
    Запрос.Выполнить().Выбрать();
по причине:
{(2, 2)}: Тип не может быть выбран в запросе
<<?>>времТЗ.УИД

(39) Битые ссылки это хрень. Нет гарантии что ид-шники таблиц будут совпадать

(41) тогда придется в виде строки, жаль что УникальныйИдентификатор не прокатил

(0) я храню ввиде текстовых GUIDов в базе приемнике. В основной базе добавил общий реквзит GUID.
В запросах связываю данные по этому реквзиту.
Пользователи даже не знают, что данные для отчетов берутся из другой базы.
Минус, что приходится использовать код т.к внешние источники данных не могут работать с другими таблицами :(
  
(1) например, база делится на 2. База оперативного учета (регистры хранят только актуальную информацию) и аналитическую базу (хранится история заполнения регистра).

(42) Если обмен односторонний - можно элементы в примнике создавать с тем же ид-шником, что и в источнике.
Тогда заморачиватся с соответствиями не надо

(40) все нормально. GUIDы нельзя выбрать в запросе, поэтому храню как текст(36)

(45) ладно, переделываю обратно на Строка(36)....

|    времТЗ.УИД
    |ПОМЕСТИТЬ времТЗ
    |ИЗ
    |    &времТЗ КАК времТЗ
    |;
    |

Заменить на

    |    ВЫРАЗИТЬ (времТЗ.УИД как Справочник.Номенклатура) как УИД
    |ПОМЕСТИТЬ времТЗ
    |ИЗ
    |    &времТЗ КАК времТЗ
    |;
    |

(47)хм, в таком случае я не уверен, что СУБД построит правильный план запроса, при соединении таблиц по полю с выражением ВЫРАЗИТЬ:

|    ВЫРАЗИТЬ (времТЗ.УИД как Справочник.Номенклатура) как УИД
    |ПОМЕСТИТЬ времТЗ
    |ИЗ
    |    &времТЗ КАК времТЗ
    |;
    |
...
ИЗ времТЗ
ЛЕВОЕ СОЕДИНЕНИЕ РегистрСведений.СоответствияНоменклатуры КАК СоответствияНоменклатуры
ПО времТЗ.УИД = ВЫРАЗИТЬ (СоответствияНоменклатуры.ИдНоменклатуры КАК Справочник.Номенклатура)