Здравствуйте!
Есть непериодический независимый регистр сведений РегистрДанных
Требуется делать много запросов вида

        Запрос=Новый Запрос;
    Запрос.Текст="ВЫБРАТЬ ПЕРВЫЕ 1
                 |    РегистрДанных.ПроцентВозн
                 |ИЗ
                 |    РегистрСведений.РегистрДанных КАК РегистрДанных
                 |ГДЕ
                 |    РегистрДанных.Дата <= &ДатаОт
                 |    И РегистрДанных.Договор = &Договор
                 |    И РегистрДанных.ТипСтр = &ТипСтр
                 |
                 |УПОРЯДОЧИТЬ ПО
                 |    РегистрДанных.Дата УБЫВ";

Эти запросы работают слишком медленно. Можно ли как-то оптимизировать запрос/структуру регистра для ускорения работы запроса?
Как я понимаю, замедляет работу условие РегистрДанных.Дата <= &ДатаОт, но что можно сделать?

Структура регистра - измерения дата, договор, ТипСтр (строка), ресурс - ПроцентВозн (число)

Срезпоследних

И регистр переодическим.

зачем МНОГО?

+(3) и убрать Дата из измерений

+(3) И в запросе по СрезПоследних условия отбора задавать в параметрах Среза, а не в ГДЕ.

(0) А "делать много запросов" - это ты чисто случайно не в цикле их делаешь? По каждому договору, например?

На всякий случай спросил

(7) Да. Поясни этот момент.

Да, в цикле, т.к. разные даты и ТипСтр

ПриВыводеСтроки :D

(10) и даже не догадался попробовать разом получить всё нужное? я уж помолчу о наименованиях

Делай условие в запросе Договор В (&ТвоиДогвора)

ТипСтр (строка) зачем? неограниченная небось еще

(14) это тип страданий, перечисление

(0) > Эти запросы работают слишком медленно.

Нормальный запрос. Другое дело может ты ими заваливаешь сервер или железо слабое. Другой подход нужен - уменьшить число запросов.

ну может там комментарии к документам хранятся

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

(10) Сформируй ТаблицуЗначений и передавай её в запрос.
Таким образом запрос будет один.

(18) протестируй, сравни результат. Нужные колонки в таблице значений можно проиндексировать

(18) зато это будет в 1000 раз быстрее. Или в 10000 раз. Наплюй на неудобства. Производительность рулит.

а еще можно сделать пакет, и отдельно выгрузить таблицы по типстр

(0) А индексы-то есть?

(19) +100500

"Разом можно получить таблицу значений, но поторм как-то из нее в цикле нужные строки извлекать кажется тоже не слишком удобным."

это просто прекрасно.

(23) см (1) [Структура регистра - измерения дата, договор,]

(16) Я считаю, что сейчас плохого железа нет - бывают плохие структуры данных. Индексы, денормализация и все такое прочее прекрасно решают эти проблемы. Вот как легче в бибилиотеке найти книгу - перекопать всю библиотеку или подойти к каталогу (считай, индексу)? Вот то-то же...

Индексы есть, буду пытаться пакеты по типстр и договору формировать, но это не слишком удобно реализовывать к сожалению.

(25) подозреваю, что ТС получит ТаблицуЗначений и будет делать
тз.НайтиСтроки(ПредварительноСозданныйОтборС_ДатаОт_Договор_ТипСтр)

(29) Ни в коем разе. Он правильно сгруппирует и выгрузит деревом. А потом сделает обход по группировкам.

(28) И еще оптимизация базируется на неожиданно простых вещах, например: есть условия A and B, так вот если A = false, то B - не проверяется, если речь идет A or B тогда если A = true B не проверяется (на проверку может тратиться оооочень немало времени. Улавливаете?

+(31) Может, попробовать условия местами поменять - запрос быстрее может пойти существенно.

(27) плохого нет, бывает железо неподходящее под задачи. Запрос в (0) попадает в индекс. Проблемы в их количестве в еденицу времени.

(32) в этом случае это конечно это никак не повлияет на результирующий запрос в бд

Это не так. Если выражение-операнд B имеет синтаксическую или логическую ошибку, то она вывалится даже в случае описанном в (31)

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

(26) И что? Он не мог сделать неиндексируемые измерения?

(27) Да, запрос в цикле - в большинстве случаев это беда

(38) к (33)

(37) > Он не мог сделать неиндексируемые измерения?

Для такого запроса не нужно специально индексировать. Достаточно "платформенного" индекса

Измерение1 + [Измерение2 +...] (Кластерный)

(40) Условие <= попадет в кластерный индекс?

(0) Измерение Дата должно быть последним в регистре.

(42) Индексировать измерения не нужно. Основной индекс по умолчанию идеально подойдет.

О, ну пошли советы по оптимизации...

Пусть ТС сначала запрос из цикла вытащить. Ставлю 10 баксов, что ему такого выигрыша в производительности с головой хватит.

(0) Думается что проблема из-за измерения ТипСтр (строка) - у него размерная какая?

я гляжу, тут никто никто не обратил внимание ни на тип ТипСтра, ни на непериодичность регистра

(45) ну, ему неудобно вытаскивать.

(44) сначала надо вытащить запросы в цикле из программиста :)

(41) да

(49) Да, но для неподчиненного регистратору.
Для РС подчиненного регистратору, SQL чаще предпочтет clastered index scan, нежели indexseek по некластерному по измерениям + keylookup.

ТипСтр - перечисление.
Без цикла - легко могу вытащить таблицу данных регистра по договорам с колонками
Договор, Дата, ТипСтр, ПроцентВозн.

Но как потом из этой таблицы извлекать данные по конкретному договору, дате, типуСтр ? Или получится один огромный запрос, подозреваю, систему повесит... очень много данных

В таблице данных регистра - строк не слишком много, а вот входяще данные договор/дата/типстр - там много тысяч элементов...

Даже сотни тысяч могут быть

(53) если данных меньше 10 миллионов строк, то по- любому один запрос будет быстрее.

По одному договору. ПроцентВозн меняется не часто.

(51) Ты в цикле еще и данные через точку извлекаешь? 0_0

(51) Может озвучишь задачу, а не твое видение ее решения?

(51) То есть у тебя лучше получается с запросами, чем с таблицами значений?
(53) Ну и что? А так у тебя каждый запрос по каждому договору считывает тот миллион записей, что находится в регистре.

(53) - думаю, меньше, а в таблицу сколько строк можно класть по максимуму?

(59) Этот вопрос регулируется исключительно твоей совестью

(59) да, и все данные договора тоже в запрос кинь. Это еще раз в 70 уменьшит время запроса.

(0)
- сколько записей в регистре
- какой длины строка в  измерении ТипСтр
- когда последний раз было обновление индексов

(0)
какой порядок измерений в регистре?

(62)(63) "... и в забег включается новый участник!"

(62) "ТипСтр - перечисление."

Измерения
Договор - СправочникСсылка
ТипСтр - Перечисление

Ресурсы
ПроцентВозн - Число

Есть много (за месяц - около миллиона) элементов справочника "ВходящиеДанные" с реквизитами "Дата (дата+время), Договор, ТипСтр (перечисление), Сумма".

Нужно для каждого элемента справочника найти соотв. ресурс регистра процентВозн (по дате/договору/типСтр) и сосчитать Сумма*ПроцентВозн с итогами по договорам

(66) Дата из периодичности регистра?

Причем соотв. ресурс регистра процентВозн ищется по условию
ДатаВРегистре <= ДатаВход (т.е. ближайшая дата из регистра).

Регистр сделадл периодическим

Но записи в регистре не за все даты

(66) тормозит выполнение одного запроса или запросов в цикле?

(69)  когда в запросе (0) идет упорядочивание, то нужна будет только первая запись или просто подготавливается таблица в выводу?

(66) "Есть много (за месяц - около миллиона) элементов справочника "ВходящиеДанные" "

Таак ,а зачем вообще тогда нужна ТЗ или еще что? Почему в запросе бы не работать с этим справочником?

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

(71) - только первая запись для конкретного элемента справочника в зав-ти от даты

(73) Т.е. ты получаешь список элементов справочника и тебе каждому элементу списка надо подобрать запись в регистре?

973) - да, так

Записей в справочнике - очень много, в регистре - мало

(75) - да, так

(78) Ты знаешь, что в запросе можно использовать ЛЕВОЕ СОЕДИНЕНИЕ или ВНУТРЕННЕЕ СОЕДИНЕНИЕ? (Про другие не буду лучше говорить)

А в ТЗ.НайтиСтроки (Отбор) в отборе можно задавать условие "<=" ? Или только "равно"?

(80) это шутка была, не нужно так делать

(79) - понял, буду переделывать запрос

(82) О, как. Даже неожиданно.

(82) из выше рассказанного тебе нужно заливать содержимое цикла во временную таблицу и делать срез последних по нескольким датам
http://kb.mista.ru/article.php?id=92