Есть ли какая то возможность из уникального индификатора достать тип документа? Например, есть индификатор и нужно понять что он допустим Справочник-Номенклатура
(12)ссылка.ПолучитьОбъект() - понятно, что медленнее, чем запрос, но не нужно опрашивать все таблицы запросом.
Можно делать только для представления ссылки "<Объект не найден ....".
(14) Я бы сделал через
ВЫБРАТЬ Ссылка ИЗ ИмяТаблицы1 ГДЕ Ссылка В (&МассивСсылок1)
ОБЪЕДИНИТЬ ВСЕ
ВЫБРАТЬ Ссылка ИЗ ИмяТаблицы2 ГДЕ Ссылка В (&МассивСсылок2)
и т.д. без соединений
(15)если учесть, что необходимо сначала получить ссылку, а ссылка получается только из менеджера объекта, то МассивСсылок будет содержать количество элементов = количество УИДов * Количество метаданных + еще время на передачу всех этих массивов в СУБД + выполнение запроса + возврат результата серверу 1С
По-мне, так проще сразу понимать, битая ссылка или нет и отсеивать ее в цикле сразу же.
(16) Для каждого типа метаданных будет свой массив ссылок, но общее количество элементов всех массивов да, будет таким. Думаю, одним запросом будет быстрее, чем каждую ссылку проверять запросом в цикле "ВЫБРАТЬ NULL ИЗ ИмяТаблицы ГДЕ Ссылка = &Ссылка".
Явно хуже запроса. Уровень запроса намного ниже предложенных вариантов и позволяет избежать лишних операции обработки данных. По сути это тоже запросы, только с избыточной обработкой.
(20)но нам придется набрать массивы ссылок, чтобы потом их проверить запросом.
Т.е. у нас будет минимальным/не будет выйгрыша, т.к. эти массивы необходимо в СУБД передать, выполнить запрос. вернуть результат.
Попробую на недельке, как раз будет задача похожая, но там типы объектов известны.
(21) Так Ссылка.ПолучитьОбъект() и Строка(Ссылка) тоже обращаются к СУБД. В случае с ПолучитьОбъект(), если ссылка не битая еще и все реквизиты и табличные части будут получены из СУБД, а потом сериализованны. Строка(Ссылка) - тоже не подарок, будут тянуться данные, необходимые для формирования представления, а если еще и переопределен обработчик ОбработкаПолученияПолейПредставления, вообще сказка.
(7) Количество соединений в запросе будет равно: количество УИДов * Количество метаданных. По вашей ссылке не самое оптимальное решение, там в комментариях есть лучше.
(8) можно, можно просто пытаться получить ссылку. Но, у автора вроде как список..а там, всё в перемежку.
тут хоть на выходе получит список готовых ссылок, если есть такие в базе с этими уидами
в 21 релизе нам обещан уникальный идентификатор в тексте запроса.
Интересно, фильтр по нему можжно ставить будет ? Или это будет такая же хрень как и Представление ссылки в тексте запроса ?
Кто в курсе ?
(24) Ага, спасибо.
Ну хоть тут не подвели. Еще лет 20 и сделают cast и convert в тексте запроса. Чтоб не было тем на форумах из строки в число, из строки в дату..
И лет через 30..коррелированный подзапрос в селект листе.
От тогда заживём.