А если сделать выборку без типизации полей - как быстро работает?

Вообще, странно - ибо типизация полей работает уже на стороне 1С, если я правильно помню.


А какой объем выборки?
И сколько времени выполняется запрос без типизации из ВТ/с типизацией из ВТ/с типизацией из таблиц базы?

1. Как уже тут спрашивали - какой объем выборки? (Вероятнее всего - очень большой)
2. Технология, собственно, такая - при типизации должны получится не "строки и ИД-шники", а "объекты 1С". Для этого самой 1С вызываются 1С-ные хранимые процедуры, при помощи которых и получаются объекты. В результате на каждый из типизируемых объектов (собственно [количество объектов] = [кол-во строк выборки] * [кол-во типизируемых полей в выборке]-[кол-во объектов, попавших в кэш на предыдущих запросах]) формируется запрос к БД, который получает все поля данного объекта.
Собственно отсюда и рекомендации:
1. Заранее подумать - какие поля потребуются в дальнейшей работе и добавить JOIN-ы к соответствующим таблицам с получением значений этих полей.
2. Так как не все поля нужно получать сразу, то заниматься типизацией в нужные моменты времени, т.е. если в каком-либо условии если возникла необходимость обратится к какому-то объекту, то получить его через MetaDataWork :: ЗначениеИзСтрокиБД

(6) Приведи тестовый пример понятный для всех.

Также не помню точно но вроде select * into копирует только таблицу
без индексов может в этом причина.

Проверил 7.
при создании таблицы с помощью
select into индексы не создаются ( даже primary key )
Вот скорее всего именно из-за этого работа с этой таблицей очень медленно происходит.
Для более точного ответа нужен понятный тестовый пример из (0)

Дело в том, что у меня регулярно используются как выборки сразу от таблиц БД, так и выборки через промежуточные ВТ.
И никаких тормозов с работой ВТ я не наблюдал.

Хотя, конечно, можно попробовать еще такое - для чистоты эксперимента:

SELECT
    VirtTab.ИмяПоля [ИмяПоля $Справочник.ИмяСправочника],
    ...
FROM
    (
	  SELECT
		*
	  FROM
		#VT VirtTab
    ) VirtTab
  

Firedragon писал(а) 23. Марта 2011 :: 00:06:


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

2) Я так понимаю, под "IDDOC в регистре" ты подразумеваешь не поле IDDOC (регистратор движения - он всегда char(9)), а какое-то измерение/реквизит типа Документ (или даже Неопределено). Но даже в этом случае у тебя или Char(13), или Char(23) - и ты точно знаешь тип (из метаданных). Соответственно, Right(9) в первом случае и нечто похожее во втором решает твою головную боль.

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

Firedragon писал(а) 23. Марта 2011 :: 07:37:

Так причем тут оптимизатор запросов.
Если у Вас в Where стоит функция  пример Funct(Field)
то индекс поля Field не может быть применен для выполнения запроса.

Объясняю все подробно, чтоб больше ни у кого ни возникло никаких вопросов. У меня есть выборка из регистра, в котором есть поле типа Документ (общий тип документа). РЕЗУЛЬТАТ ВЫБОРКИ ИЗ РЕГИСТРА Я ЛОЖУ В ВИРТУАЛЬНУЮ ТАБЛИЦУ, ИМЕННО ЕЕ Я ИМЕЮ В ВИДУ ПОД СЛОВАМИ "ВЫБОРКА ИЗ РЕГИСТРА" ВПОСЛЕДСТВИИ (с рестром больше не работаю). Из-за того, что у нашего чудесного 13-тисимвольного поля  тип неопределенный документ (Документ), длина данного поля не 9 символов (как должно быть), а 13, т.к. 1С прибавляет слева еще 4 символа, которые в свою очередь являются 36-тиричным значением IDDOCDEF (это был не код базы как я по ошибке предположил ранее!). А т.к. мне необходимо приджойнить журнал по IDDOC, то просто так этого сделать не получится. Отсюда есть 2 выхода:
1) прибавлять к IDDOC журнала 36-тиричное значение IDDOCDEF все того же журнала и пихать этот симбиоз в условие связывания ON моего джойна результата выборки из регистра с журналом по чудесному 13-символьному полю типа Документ (это сразу отмел, кто знает что такое перевод из 10-тичного числа в 36-тиричное, тем более реализованный на скуле, тот поймет почему);
2) отнимать от нашего 13-символьного поля регистра эти самые четыре символа и сделать с ним все тоже самое, что и с симбиозом в 1)-м пункте. На этом я и остановился.
Я знаю что поле IDDOC журнала длиной 9 символов, но для универсальности решил извлекать его длину через DATALENGTH и пихать результат в RIGHT. Получилось примерно такое условие связывания

...
ON RIGHT(#VT.ЧудесноеПолеДокумент, DATALENGTH(_1SJourn.IDDOC)) = _1SJourn.IDDOC
... 

Так вот при такой постановке условия все работает ужасно медленно. А вот если вообще убрать DATALENGTH(_1SJourn.IDDOC) и поставить 9 или же

DECLARE @LENIDDOC int;
SET @LENIDDOC = (SELECT TOP 1 DATALENGTH(IDDOC) FROM _1SJourn);

SELECT
...
ON RIGHT(#VT.ЧудесноеПолеДокумент, @LENIDDOC) = _1SJourn.IDDOC
... 

то все работает просто замечательно (секунд 10 вместо 5 минут). При чем ну тут непроиндексированность поля ЧудесноеПолеДокумент? Оно в обоих случаях участвует в запросе. Конечно можно предположить тогда, что поле IDDOC журнала 1C непроиндексировано, ведь именно его вместе с DATALENGTH мы исключаем во 2-м примере из основного запроса, но это полный бред. Здесь очевидно что все трмоза из-за DATALENGTH в условии связывания и ни о какой непроиндексации каких либо полей речи идти не может. Надеюсь все прояснилось?

+ к (18) и еще надо чтобы по полю
#VT.Doc был индекс  ( о чем уже неоднократно упоминалось )

НУ и саму такую таблицу #VT надо понимать что сразу же после создания такая таблица может устареть если кто то перепроведет документ затрагивающий этот регистр.

PS и я считаю что в посте 18 слово можно надо заменить на слово Нужно

А что мешает в ВТ писать И идДок9 И идДок13?

К тому же - если _1SJourn все-равно джойнится, то можно типизацию $Документ сделать через 2 поля:
_1SJourn.IDDoc [Док $Документ],
_1SJourn.IDDocDef Док_вид

_1SJourn.IDDoc [Док $Документ] такое приведение невозможно, потому как поле длиной всего 9 символов. При попытке выполнения подобного запроса вылазит ошибка "Для типизации поля "док", не найдено дополнительное типизирующее поле."

Док_вид