v7: Проблема с табличным полем. 1С++ #735908

Есть череда документов для склада, как-то Розничная, Расходная, Перемещение, Счет и т.п. Эти виды документов ставятся на сборку и склад их собирает. Документ ставится на сборку изменением статуса и даты "Собрать к". Соответственно есть журнал сборки на основе табличного поля, запрос типичный проблема в том, что если интервал дат большой, журнал будет тормозить при выборке. Соответственно рекомендовал складу уменьшить интервал просмотра. Есть старые счета, согласование которых длительно и клиент иногда соглашается оплатить счет месячной давности, если поставить на сборку старый счет, то счет в журнале не виден. Как теоретически ускорить запрос? Кто-нить со вьювами работал? сделал вьюв по выборке, подумал его индексировать, но уперся в "Cannot create index on view 'JournAssembly2015' because the view is not schema bound". У кого есть опыт работы со вьювами в скуле?

какие условия надо соблюсти, что-бы его можно было проиндексировать?

Уже всю голову сломал.

За скуль не знаю. Но помню, когда возился с подобным для ДБФ (SQLiteDataProvider) - запрос выполнялся для видимых строк. Не помню вот это свойство ТП или SQlite. А то может имеет смысл еще раз перечитать доку :)

Да вот курю доки. Уже пол дня. Фиговый табачек у мелкософта - у меня 2 скуля, 2000 и 2005 в работе, на 2005 дока на мелкосайте есть, а по 2000-му только BOL на скврноинглише.

Поднял CHM от SQLite, формировать запрос лишь для видимых - это прерогатива SQLiteDataProvider, ТП так не умеет само по себе. У ТП вроде как поставщик необходимо объявлять? ИМХО надо сначала проработать этот вопрос с ним. Когда читал доку по 1С++ точно помню было сколько-то инфы о разл. поставщиках.

Тема по MS SQL-серверу. И оптимизаднице запросов.

На всякий.

Я обычно в условие добавляю ВидДокумента LEFT JOIN $Документ.РасходнаяНакладная as ДокРН (NOLOCK) ON (Жур.IDDocDef=$ВидДокумента.РасходнаяНакладная) And (ДокРН.IDDoc = Жур.IDDoc)

Это есть.

>проблема в том, что если интервал дат большой, журнал >будет тормозить при выборке. Соответственно я что-то не понимаю почему он тормозит на большом периоде? при связке Табличное Поле + Поставщик: "ODBCDataProvider.MSSQL" выполняется select top <количество видимых строк>. и в этом случае период вообще не должен влиять на тормоза...

у меня "достаточно тяжелые запросы", но при связке Табличное Поле + Поставщик: "ODBCDataProvider.MSSQL" у меня все выстреливает как из пушки.

а не надо путать счета (сфера ответсвенности манагеров) и задания на сборку (сфера ответственности склада).

Например, создать свою табличку, писать туда нужную для отбора инфу. На эту табличку навесить правильный индекс. Инфу писать триггерами. В общем, это типа как-бы "графа отбора", только грамотно сделанная. Ещё, когда у тебя в запросе используются шапки док-ов разного вида, то лучше не лепить кучу джойнов, а делать так: select     Журн.Date_Time_IDDOC as Порядок,     Журн.идДок13 as Документ,     (6*Журн.IsMark + (Журн.Closed&1)) as Пиктограмма,     Журн.НомерДок as Номер,     Left(Журн.Date_Time_IDDOC, 8) as Дата,     Док.ВидДок as ВидДок,     Док.Касса as Касса,     Док.Приход as Приход,     Док.Расход as Расход from         ...     ) Док ON Док.идДок9 = Журн.идДок9 where

ЖурналДокументов, идДок13 .... ты сейчас взорвешь автору мозг :)

да ладно, смысл то понятен, я думаю человек вьюхи упоминал, стало быть в курсе

да, код понятен.

SELECT Реализация.IDDOC [Ссылка $Документ.Реализация] FROM _1SJOURN AS Журнал With (NOLOCK)     INNER JOIN $Документ.Реализация AS Реализация With (NOLOCK) ON Журнал.IDDOC = Реализация.IDDOC ..... Так как по IDDOCDEF  есть индекс IDDOCDEF,DATE_TIME_IDDOC

смысла нет, ну, т.е в производительности не выиграешь

Есть конечно еще выделить их в журнал и отбирать по журналу IDJOURNAL,DATE_TIME_IDDOC Или использовать графу отбора

А индексированную вьюху по шапкам шескольких документов приходилось кому делать? Срослось?

Аргументируй. По сравнению с первым ему придется пройтись по всему журналу в том числе по тем видам которых нет в списке. И если таких документов будет много то выигрыш будет явным. В любом случае в Соединение идет без учета вида документа .   Пусть автор выдаст данные эксперимента

индекс по IDDocDef задействуется условием where     Журн.IDDocDef IN (2306, 11087, 2296, 11097, 38560, 2574) а также сортировкой по Date_Time_IDDoc, которое потом ТП накладывает. Большего не выжмешь. Пытались в своё время в этом направлении копать, но что-то не вышло. Что именно не устроило даже не помню. Собственно, тогда и остановились на вспомогательных табличках.

> Пытались в своё время в этом направлении копать, но что-то не вышло. Да вот тоже вчера не вышло. Индекс невозможно построить если вюха не в схеме, а если вьюха в схеме, то начинаются другие проблемы. Хотел проблемы переложить на секвак, но не вышло.

А как отобрать документы по дополнительному жкрналу? Понятно что _1scrdoc MdId а есть аналог как $ГрафаОтбора ?

Хотя вьюха, даже не индексированная, дает определенный выигрыш по производительности на клиенте.

самое главное преимущество вьюх - это то, что запросы можно писать по русски, без всяких метапарсеров :)

Еще раз внимательно прочитай . Тебе придется пройтись по строкам всего журнала и отбрасывать по ходу ненужные и если таких позиций много ты будешь терять на этом время. Хотя конечно это копейки.

27+ у него проблема с большой выборкой. А вообще обычная болезнь искать глазами в журнале, а не алгоритмами поиска

неа, будет индекс сик в плане запроса и задействован индекс по виду дока

нафиг мне читать , когда я могу почитать план запроса? И он кажет индекс скан по IDDOCTYPE (0%) + seek по PK (49%)  + clustered index seek по табличкам документов (48% в сумме)

(29,30) Каюсь был неправ. Ёпрст ответь на вопрос в 24

разве что свою табличку лепить

> самое главное преимущество вьюх - это то, что запросы можно писать по русски, без всяких метапарсеров :) Ну так тоже самое может дать обычная табличка+тригеры.

да не, я про другое у меня на все 1С-ные таблички (справочники, документы, журналы, регистры) автоматически генерируются вьюхи с русскими именами. После чего я могу писать запросы по русски, как в 1С, так и в SSMS. Очень удобно.

т.е. это тупые синонимы табличек, к примеру: FROM DH3191 WITH (NoLock)

Понятно. Не слишком ты загемороил попусту сервак? На поддержание вьюва нужны ресурсы.

ты не поверишь, но mdid = $ЖурналДокументов.ТвойДопЖурнал

я думаю, он немного про другое спрашивал, не ?..

я думаю он это и спрашивал "А как отобрать документы по дополнительному жкрналу? " документы по доп журналу отбираются из _1scrdoc c условием как я указал

Спасибо так и предполагал, но не нашел в интернете использования $ЖурналДокументов Упущение это исправлю для выборки по дополнительному журналу SELECT Журнал.IDDOC [Документ $Документ] FROM _1SCRDOC AS Отбор With (NOLOCK)     INNER JOIN _1SJOURN AS Журнал With (NOLOCK) ON Отбор.CHILDID = Журнал.IDDOC

вот это все портит, ты не попадаешь в индекс и сканируешь весь журнал вне зависимости о дат

ON right(Отбор.CHILD_DATE_TIME_IDDOC,9) = Журнал.IDDOC то избавишься от ненужного bookmark lookup

Я конструкторм пользуюсь. Лениво руками править. Но обычно использую between А вот со 42 не совсем согласен, т.к. по IDDOC индекс и он короче а значит страниц с индексом меньше и поиск быстрее.

"Я конструкторм пользуюсь. Лениво руками править. Но обычно использую between " дело то не в битвине "А вот со 42 не совсем согласен..." уговаривать не стану

Какие все умные я с вас балдею

лучше б спрашивал побольше, а не балдел :))

да вот надобности блин постоянной нет Эпизодически только Вот как начну свою нетленку кропать то тут меня и попрет понесет Готовьтесь короче

Блин правда я обещаю с 2013 года

Посыл то я понял использовать данные индекса для соединения. Спасибо. Со второй частью я полностью согласен. ON right(Отбор.CHILD_DATE_TIME_IDDOC,9) = Журнал.IDDOC Что бы добить тему с отбором по виду журнала SELECT Журнал.IDDOCDEF [Документ_вид $ВидДокументаПредставление] FROM _1SJOURN AS Журнал With (NOLOCK) Сейчас не могу получить план запроса, но он и при таком условии отрабатывает мгновенно и точно не сканирует весь журнал. Хотя согласен, что правилнеее использовать

"но он и при таком условии отрабатывает мгновенно и точно не сканирует весь журнал" ну да, в плане ты увидишь index seek, но seek этот будет только по полю IDJOURNAL ключа, а не по полному ключу и записи в рамках конкретного значение IDJOURNAL он будет сканировать от начала времен до конца я тебе это гарантирую

обрати внимание на выражение в SEEK: в не правильном и правильном варианте Index Seek(OBJECT:([xxx].[dbo].[_1SJOURN].[JOURNAL] AS [Журнал]), SEEK:([Журнал].[IDJOURNAL]=5026),  WHERE:(Convert(substring(Convert([Журнал].[DATE_TIME_IDDOC]), 1, 8))<='Jan 31 2015 12:00AM' AND Convert(substring(Convert([Журнал].[DA Index Seek(OBJECT:([xxx].[dbo].[_1SJOURN].[JOURNAL] AS [Журнал]), SEEK:([Журнал].[IDJOURNAL]=5026 AND [Журнал].[DATE_TIME_IDDOC] >= '20150101' AND [Журнал].[DATE_TIME_IDDOC] <= '20150131z') ORDERED FORWARD)

Какой SQL?

2000 но это не имеет значения

Согласен. Видно держит всю таблицу в памяти Такой тоже отрабатывает незаметно на глаз. SELECT  Журнал.DATE_TIME_IDDOC ДатаВремяИдДок ,Substring(Журнал.DATE_TIME_IDDOC,Len(Журнал.DATE_TIME_IDDOC)-3,4) Длина FROM _1SJOURN AS Журнал With (NOLOCK) WHERE (Substring(Журнал.DATE_TIME_IDDOC,Len(Журнал.DATE_TIME_IDDOC)-3,2) = 'IX')

"незаметно на глаз." ну, это не научный метод

Согласен. Время для прохода нескольких миллионов записей может быть меньше чем отправка данных по сети.