ааблинсвососкобками! дважды ялох! простите. щяс...
Added:
Блинство. В регистре Фирма и Товар - первые измерения. Пошёл в склайт для скорости. и на тебе:

Подбор индекса для таблицы RA1173:
	Ограничения: SP1159[Товар]=;
	Упорядочить: SP1158[Фирма], SP1163[Поставка], SP1164[ПрихДокумент], IDDOC,
	В кэше не найдено
	Индекс не выбран.
	Стоимость: 9978 

- и результат - ПУСТОЙ!.. хотя партии там есть точно!

tsarevich писал(а) 14. Марта 2012 :: 09:29:

Убрал. Выборка не пустая, НО: стоимость индекса всё та же дикая, и колонка "Документ" НЕ заполнена.

Прим: Убрал типизацию для IDDOC и добавил ", Count(Партии.IDDOC)" в SELECT.
В результате - заполненная rолонка IDDOC (краткими(!) ИД-ами), однако в колонке "Count(Партии.IDDOC)" почему-то встречаются не(!)единицы (двойки) - но почему? счетчик же по последней группировке..

ЗЫ: и - опа, мне только ПРИХоды нужны (это помимо фильтра по кодам операций)...  

tsarevich писал(а) 14. Марта 2012 :: 10:06:

Вотжешблинство. А если я не знаю сколько фирм? и сколько товаров? но мне по этим двум первым измерениям надо отбор делать? что, способов найти дещёвый индекс нету?

Цитата:

Как раз измерения типа "документ" (неопр) в результат прекрасно попадают с такой типизацией.
в RA-таблице есть поле IDDOCDEF. но епри попытке сунуть его в селект - говорит что такой колонки нету. странно, в одних есть, в других нету..
с журналом вязаться? ну тут я вообще увязну.  
Цитата:

мне нужны ВСЕ ПРИХоды - кстати, DEBCRED 0/1 это прих/расх? (аблин, надо сначала попробовать - может тоже как на iddocdef ругнется)
(ну или на крайняк - последний(в хронологии) приход по (последнему из) заполненному поставке или прихдоку (себестоимость последнего прихода короче).

ЗЫ: и всё-таки! как же фильтр на вид операции (реквизиту - однознаковой строке) по вхождению наложить???

tsarevich писал(а) 14. Марта 2012 :: 10:40:

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

Цитата:

Там я исправил. в нужном регистре нету такого флага - и поля тоже.. буду гробиться связку с журналом строить для выдергивания вида документа и как-то (как, блин?) получить чтобы документ движения... или не буду - блин, невозможность существенного ускорения при множественном отборе на первые реквизитвы просто убивает.  

Цитата:

вот спасибочки.


Цитата:

Оприходование излишков. Хитрое. Чтобы стоимость - по последней актуальной (а это не всякая поставка - тоже геморрой) поставке.

Цитата:

1с++ не юзаю, только 1sqlite. 1с++ мне периодически валит одинэсину - хрензнает при каких условиях, закономерность не удалось отловить, угробив кучу времени. и это - очень неприятно! хорошо что только начал на него переписывать кусочки - обратно отыгрывать пришлось...

ИТОГО:
всем спасибо, вопрос снят или отложен до появления свободного времени - прямой запрос не даст выигрыша ибо нужных индексов в партиях нету (отборы движений по фирме, товару и вообще - не стоят, а тут ещё как-то вязаться с журналом надо - вытаскивать вид докуменнта, как-то пристёгивать его к иду документа и как-то выдергивать документ).
 

не может. это поле присутствует в журнале. а там все IDDOC-и уникальные

ну.. завтра попробую смоделировать ситуацию.. с работы уже рву...

Цитата:


Будем исходить из следующих условий:
1.      У тебя 2 фирмы(можно и больше, т.к. все равно формируется список)
2.      Товар так же укладываем в список, т.к. возможна выборка группы или нескольких элементов . ну я так захотел :
3.      Ну и присутствует ограничение по датам документов- это можешь выкинуть...
4.      Далее.. не знаю, какую роль у тебя играют измерения Поставка и ПрихДокумент ??? так что буду отбирать записи с документами движения (IDDOC), где debkred = 0. Если, к примеру ПрихДокумент- это партиеобразующий документ, можно вместо IDDOC брать его- все равно перебираем движения…


     ТекстЗапроса = "
     |Select
     |   Партии.iddoc[ДокПрихода :Документ],
     |   Журнал.iddocdef ДокПрихода_вид,
     |   count(Партии.iddoc) КолДвидженийДоковПрихода
     |from Регистр_ПартииТоваров Партии
     |inner join Журнал on Партии.iddoc =  Журнал.iddoc
     |where
     |  Журнал.date between :НачДата and :КонДата and Журнал.ПартииТоваров ФР = 1 and Партии.debkred = 0
     |  and Партии.Фирма in (select val from СпсФирмы)  
     |  and Партии.Номенклатура in (select val from СпсТовары)
     |group by
     |  Партии.iddoc,Журнал.iddocdef
     |";        
     
база.УложитьОбъекты(ВыбТМЦ,"СпсТовары" , , "Номенклатура"); // ВыбТМЦ – возможно это будет один товар, группа товаров, список товаров и т.д.
// в СпсФирмы загружаем 2 фирмы.
СпсФирмы = СоздатьОбъект("СписокЗначений");
СпсФирмы.добавитьЗначение(ВыбФирма1);
СпсФирмы.добавитьЗначение(ВыбФирма2);
база.УложитьОбъекты(СпсФирмы,"СпсФирмы" , , "Фирмы");

Запрос.Подставлять("КонДата",КонДата);
Запрос.Подставлять("НачДата",НачДата);
Запрос.Подготовить(ТекстЗапроса);
запрос.отладка(1);
запрос.Выполнить().выбратьстроку();

Что касается стоимости индекстов:
В регистре движений партии индексы по измерениям регистров появятся только при установке в измерениях опции «Отбор движений». Возможно после этого скорость выборки возрастет. Но вследствие чего распухнет CDX файл таблицы движений. Пример: в моей базе таб. Движения партий = 90 Мб, cdx = 4 Мб. Установил в измерениях фирма и номенклатура отбор движений. Долго сохраняла конфу. После этого CDX стал 30 Мб. Ну и скорость записи в регистр упадет- насколько не знаю- не проверял. Не думаю, что намного…
Но несмотря на отсутствие индексов по измерениям в движениях, выборка у меня была примерно такая: с 01/01/11 по текущий день, по двум фирмам и по группа в которой у нас лежит очень дофига товаров – длилась ~ 5 секунд при первом запуске, 3 сек.- при последующих. Начало движения в партиях- с середины 07 года, всего записей в движенях - примерно 1400000. Штатным способом выборка была бы однозначно не такая.

Связь с журналом делаем тогда, когда например нужна типизация документов неопределенного вида,  когда нужно ограничивать выборку по датам движений. Исключение -  когда в регистре установлен флаг «Быстрая обработка движений».
Это добавляет в таб. движений поля IDDOCDEF, DATE, TIME.

Что касается блокировки таблиц- вроде по умолючанию блокировок нет. но можно их установить принудительно. для этого есть свойство запроса ВыполнятьВТранзакции
Вроде все...уф.. многабукаф...