| 0
- 05.08.2012 - 19:47
|
Штатным методом не получается - не загружаются в УТ поступление тмц, комплектация, оприходование и списание. Все заявки (неподтвержденые и обычные) загрузились как просто заявки на склад. В файл обмена выгружаются все документы. А вот УТ их режет. В чём может быть причина? Что посмотреть/сравнить? Подскажите, пожалуйста, кто сталкивался. )     | | |
| 81
- 09.08.2012 - 10:05
| (75) "При использовании СКД глубоко фиолетово какую таблицу юзать в запросе - регистр или документ. Лишь бы в индексы попасть." Не верится. Виртуальные таблицы фактически обращаются в таблицам итогов, разве нет? | | |
| 82
- 09.08.2012 - 10:21
| В отчете ЗаказТовараУПоставщиков запрос ВЫБРАТЬ Продажи.Товар КАК Товар, Продажи.Количество КАК Количество_Продано, Продажи.Сумма КАК Сумма_Продано, ЕСТЬNULL(регОстатки.КоличествоОстаток, 0) КАК Количество_Остаток, ПРЕДСТАВЛЕНИЕССЫЛКИ(Продажи.Товар) КАК ТоварПредставление, Продажи.Товар.Наименование КАК ТоварНаименование ИЗ (ВЫБРАТЬ Продажи.Товар КАК Товар, СУММА(Продажи.Количество) КАК Количество, СУММА(Продажи.Сумма) КАК Сумма, Продажи.Склад КАК Склад ИЗ (ВЫБРАТЬ регПродажи.Товар КАК Товар, регПродажи.КоличествоОборот КАК Количество, регПродажи.СуммаСоСкидкойОборот КАК Сумма, регПродажи.ДокументПродажи.Склад КАК Склад ИЗ РегистрНакопления.Продажи.Обороты(, , , ) КАК регПродажи ГДЕ регПродажи.ДокументПродажи.Склад = &Склад ОБЪЕДИНИТЬ ВСЕ ВЫБРАТЬ регОстатки.Товар, регОстатки.Количество, регОстатки.Количество * регОстатки.ЦенаРеализации, регОстатки.Склад ИЗ РегистрНакопления.ОстаткиТоваров КАК регОстатки ГДЕ ТИПЗНАЧЕНИЯ(регОстатки.Регистратор) = ТИП(Документ.РасходнаяНакладная) И регОстатки.Склад = &Склад) КАК Продажи СГРУППИРОВАТЬ ПО Продажи.Товар, Продажи.Склад) КАК Продажи ЛЕВОЕ СОЕДИНЕНИЕ Справочник.Номенклатура КАК спрТовары ПО (спрТовары.Ссылка = Продажи.Товар) ЛЕВОЕ СОЕДИНЕНИЕ РегистрНакопления.ОстаткиТоваров.Остатки(, Склад = &Склад) КАК регОстатки ПО (регОстатки.Товар = Продажи.Товар) ГДЕ спрТовары.фНеЗаказываем = ЛОЖЬ Я, конечно, выберу время и перецарапаю базу в скуль. И гляну план запроса. Но, честно говоря - запрос-то элементарный.. | | |
| 83
- 09.08.2012 - 10:22
|
79-Reaper >тех. журнал у 8.2.15 умеет даже для файловой версии собирать планы выполнения запросов. Поставил себе галочку. Спасибо за информацию. | | |
| 84
- 09.08.2012 - 10:23
|
79-Reaper > Про регистр Продажи спорить не буду. Буду думать и экспериментировать. Хотя, честно говоря, не хотелось бы, что бы в него расходная что-то писала... | | |
| 85
- 09.08.2012 - 10:26
|
81-Пудель >Виртуальные таблицы фактически обращаются в таблицам итогов, разве нет? Не совсем понял вопрос. Виртуальные таблицы, разумеется, обращаются к реальным таблицам (итогов и движений), так как "виртуальная таблица" - это всего лишь запрос. | | |
| 86
- 09.08.2012 - 10:30
| Цитата:
| | |
| 87
- 09.08.2012 - 10:36
| 86-bma1 > Нет, не вижу. Так как в исходной посылке было "лишь бы в индексы попасть". | | |
| 88
- 09.08.2012 - 10:48
| Через какой драйвер у тебя заведены сканера? COM или эмуляция клавиатуры? | | |
| 89
- 09.08.2012 - 10:50
| (84) Запили в него еще пару ресурсов "Количество по расходным" и "Сумма по расходным", если так логика устроена жестко. | | |
| 90
- 09.08.2012 - 10:57
|
88-Reaper > Еще хлеще... Эмуляция СОМ-порта на USB. 89-Reaper > Нафиг-нафиг. Итоги вспухнут и время записи увеличится. | | |
| 91
- 09.08.2012 - 11:04
|
(85) ну вот значит и не всё равно, по документам или по регистрам собирать данные. (82) Ужас :) 1. Вот это плохой фрагмент, должен сильно тормозить: "ВЫБРАТЬ регОстатки.Товар, регОстатки.Количество, регОстатки.Количество * регОстатки.ЦенаРеализации, регОстатки.Склад ИЗ РегистрНакопления.ОстаткиТоваров КАК регОстатки ГДЕ ТИПЗНАЧЕНИЯ(регОстатки.Регистратор) = ТИП(Документ.РасходнаяНакладная) И регОстатки.Склад = &Склад" здесь плохо всё :) 2. "ГДЕ регПродажи.ДокументПродажи.Склад = &Склад" Вот это условие пихать в виртуальную таблицу конечно, а не снаружи накладывать. Параметр условие в виртуальной таблице не просто так введён, разница очень большая. 3. "ЛЕВОЕ СОЕДИНЕНИЕ Справочник.Номенклатура КАК спрТовары ПО (спрТовары.Ссылка = Продажи.Товар)" вот это не нужно. Если не устраивает вторая точка Продажи.Товар.фНеЗаказываем , то лучше предварительно подготовить список подходящих и не подходящих товаров, временной например таблицей. И это условие обязательно накладывать внутри виртуальных таблиц, опять же. Если не верится - проверять низкоуровневый запрос формирования виртуальной таблицы. | | |
| 92
- 09.08.2012 - 11:09
|
91-Пудель > ну вот значит и не всё равно, по документам или по регистрам собирать данные. Абсолютно все равно. И то и другое - таблица. Главное - попасть в индекс. И, если есть, более свернутые данные - пользоваться именно ими. По поводу запроса. Извини, но ты фигню полнейшую написал... | | |
| 93
- 09.08.2012 - 11:10
|
(90) Да ничего там не вспухнет у оборотного регистра. (91) А ты представь что с этим запросом может СКД наколбасить... | | |
| 94
- 09.08.2012 - 11:13
|
93-Reaper > Как это не вспухнет? Итоги-то оно куда-то записывать должно. И предварительно считать их. Около 3-х тысяч активных SKU помножим на 3 склада, 2 ресурса... | | |
| 95
- 09.08.2012 - 11:16
| (92) :) ну мучайтесь дальше | | |
| 96
- 09.08.2012 - 11:17
| 95-Пудель > Ты непрозрачно намекаешь, что 1С-кий оптимизатор - еще хуже, чем я о нем думаю? | | |
| 97
- 09.08.2012 - 11:20
|
Он не хуже, он другой :). Дело в том, что наложение условия внутри виртуальной таблицы и снаружи в ряде случаев отличается и по результатам, яркий пример - срез последних регистра сведений. Но в данном конкретном случае внешнее условие отличается от условия в параметре виртуальной таблицы только тем, что будет сильно тормозить. | | |
| 98
- 09.08.2012 - 11:25
| (94) Ты попробуй ;) | | |
| 99
- 09.08.2012 - 11:44
|
Допекли :) Перекинул базу в скуль. Перестаньте наговаривать на 1С-кий оптимизатор. Всё нормально с ним. Он по честному нифига не делает с запросом. По крайней мере, в данном случае. ТИПЗНАЧЕНИЯ(регОстатки.Регистратор) = ТИП(Документ.РасходнаяНакладная) И регОстатки.Склад = &Склад" здесь плохо всё :) Всё нормально здесь. Имеем, как минимум, попадание в индекс _AccumRg115_ByRecorder_RN. Единственно, что, возможно, требуется сделать - проиндексировать измерение Склад. Но имея всего 3 склада, получим на столько фиговую селективность, что лучше этого не делать. Вот это условие пихать в виртуальную таблицу конечно Монопенисуально. 1С-кий оптимизатор плевал на это, а скулевый прекрасно разобрался. "ЛЕВОЕ СОЕДИНЕНИЕ Справочник.Номенклатура КАК спрТовары ПО (спрТовары.Ссылка = Продажи.Товар)" вот это не нужно. Если не устраивает вторая точка Продажи.Товар.фНеЗаказываем , то лучше предварительно подготовить список подходящих и не подходящих товаров, временной например таблицей. Работая через вторую точку как раз получим левый джоин. Что я явно прописал в запросе и четко вижу, что будет выполняться. Вариант со временной таблицей - более худший из-за большего расхода ресурсов. | | |
| 100
- 09.08.2012 - 11:45
|
Что бы не быть голословным и на предмет пнуть меня, если я что-то просмотрел, вот: SELECT T1.Q_003_F_000RRef, T1.Q_003_F_001_, T1.Q_003_F_002_, ISNULL(CAST(T8.Fld117Balance_ AS NUMERIC(27, 3)),@P1), T1.Q_003_F_000RRef, T10._Description, T10._Description FROM ( SELECT T2.Q_001_F_000RRef AS Q_003_F_000RRef, CAST(SUM(T2.Q_001_F_001_) AS NUMERIC(38, 8)) AS Q_003_F_001_, CAST(SUM(T2.Q_001_F_002_) AS NUMERIC(38, 8)) AS Q_003_F_002_, T2.Q_001_F_003RRef AS Q_003_F_003RRef FROM ( SELECT T3.Fld161RRef AS Q_001_F_000RRef, T3.Fld164Turnover_ AS Q_001_F_001_, CAST(T3.Fld166Turnover_ AS NUMERIC(30, 5)) AS Q_001_F_002_, T5._Fld412RRef AS Q_001_F_003RRef FROM ( SELECT T4._Fld161RRef AS Fld161RRef, T4._Fld162RRef AS Fld162RRef, CAST(SUM(T4._Fld166) AS NUMERIC(33, 8)) AS Fld166Turnover_, CAST(SUM(T4._Fld164) AS NUMERIC(32, 8)) AS Fld164Turnover_ FROM _AccumRgTn168 T4 WITH(NOLOCK) GROUP BY T4._Fld161RRef, T4._Fld162RRef HAVING (CAST(SUM(T4._Fld166) AS NUMERIC(33, 8))) <> @P1 OR (CAST(SUM(T4._Fld164) AS NUMERIC(32, 8))) <> @P1 ) T3 LEFT OUTER JOIN _Document78 T5 WITH(NOLOCK) ON T3.Fld162RRef = T5._IDRRef WHERE (T5._Fld412RRef = @P2) UNION ALL SELECT T6._Fld116RRef AS Fld116RRef, CAST(T6._Fld117 AS NUMERIC(27, 3)) AS Fld117_, (T6._Fld117 * T6._Fld248), T6._Fld422RRef AS Fld422RRef FROM _AccumRg115 T6 WITH(NOLOCK) WHERE (T6._RecorderTRef = @P3) AND (T6._Fld422RRef = @P2) ) T2 GROUP BY T2.Q_001_F_000RRef, T2.Q_001_F_003RRef ) T1 LEFT OUTER JOIN _Reference7 T7 WITH(NOLOCK) ON (T7._IDRRef = T1.Q_003_F_000RRef) LEFT OUTER JOIN ( SELECT T9._Fld116RRef AS Fld116RRef, CAST(SUM(T9._Fld117) AS NUMERIC(32, 8)) AS Fld117Balance_ FROM _AccumRgT119 T9 WITH(NOLOCK) WHERE T9._Period = @P4 AND ((T9._Fld422RRef = @P2)) GROUP BY T9._Fld116RRef HAVING (CAST(SUM(T9._Fld117) AS NUMERIC(32, 8))) <> @P1 ) T8 ON (T8.Fld116RRef = T1.Q_003_F_000RRef) LEFT OUTER JOIN _Reference7 T10 WITH(NOLOCK)ON T1.Q_003_F_000RRef = T10._IDRRef WHERE (T7._Fld277 = @P5) | | |
| 101
- 09.08.2012 - 11:49
| Тебе план запроса или приемлемую работу в файловом варианте? | | |
| 102
- 09.08.2012 - 11:52
|
А вот что 1С-ка вытворяет дальше - это уму не растяжимо... Башку за такое отрывать надо. Гора: exec sp_executesql N'INSERT INTO #tt1 (_INVALUELISTRRef) VALUES(@P1)',N'@P1 varbinary(16)',0xBB73001E101F8C0511E0DB5E8F22AB10 Для конечного: SELECT T1._IDRRef, T1._IDRRef, T1._Description, T1._ParentIDRRef, T1._Description FROM _Reference7 T1 WITH(NOLOCK) WHERE T1._IDRRef IN (SELECT T2._INVALUELISTRRef AS INVALUELISTRRef FROM #tt1 T2 WITH(NOLOCK) WHERE T2._INVALUELISTRRef IS NOT NULL) | | |
| 103
- 09.08.2012 - 11:52
| Я имел в виду переделать и сравнить, вообще-то, а не анализировать то, что получается по исходному варианту. | | |
| 104
- 09.08.2012 - 12:02
|
101-Reaper > Э... А в контексте 1С есть разница? Хотя... Это де 1С, че я фигню говорю. 103-Пудель > Ради интереса чуть позже попробую. Если, вдруг, в твоем варианте будут улучшения в плане скорости - потеряю веру в человечество и убьюсь веником. | | |
| 105
- 09.08.2012 - 12:02
|
Совсем печально... Садовников полез своими руками клюшечника и скульщика в восьмерку... Видимо, ув.Садовников не в курсе про таблицы агрегатов и те извращения, что делает "оптимизатор" (хотя можно ли ЭТО так называть) при расчете всяких виртуальных таблиц. ПЫСЫ: Условие ТипЗначения(Регистратра) = "что то там" в любом случае херит всю концепцию регистров-агрегатов. За такое надо бить лицо!!! | | |
| 106
- 09.08.2012 - 12:03
|
105-Lexusss > Восьмерка опровергла все законы реляционных баз данных? Условие ТипЗначения(Регистратра) = "что то там" в любом случае херит всю концепцию регистров-агрегатов. Расшифруй чуть более подробно? Мне правда интересно. | | |
| 107
- 09.08.2012 - 12:11
| и те извращения, что делает "оптимизатор" Я, конечно, всегда понимал, что хороший семерочник - это тот, кто хорошо знает теорию БД, язык 1С и умеет всем этим пользоваться, а хороший восьмерочник - это тот, кто знает как можно больше косяков платформы. Но что б на столько... | | |
| 108
- 09.08.2012 - 12:16
|
(106) Ты, видимо, живешь в прекрасном мире третьей нормальной формы? В реальности гораздо приятнее иметь таблицу-агрегат с подбитыми помесячными итоговыми цифрами с выручкой по конкретной номенклатуре, нежели бегать каждый раз к 1000 реализациям оной в базе. Пусть будем тратить время на ее актуализации и рисковать блокировками, но профит покруче! Соответственно, для получения данных этого запроса в любой типовой 1С и любой другой из плотно видимых мной ERP (SAP, NAV, вроде в DAX та же петрушка) для получения выручки мы идем не в таблицу движений, а к некоторой таблице агрегатов (вроде lookup-таблицы). Причем поддержание этой таблицы выполняет сама платформа за счет тригеров вообще без нашего участия. Я даже спрашивал у моего преподавателя по программированию в NAV, в каких физических таблицах и как организовано хранение агрегатов. На что получил простой ответ - ХЗН, это никому не надо. :))) (107) Извращение <> косяку. Просто зачастую смотреть на результат трансляции какого либо механизма 1С на уровень SQL весьма познавательно. Но такие вещи иногда увидишь - диву даешься. Та же самая обработка "В ИЕРАРХИИ" или RLS на запись по табличной части... Эпичнейшие вещи!!! | | |
| 109
- 09.08.2012 - 12:21
|
108+ Причем в NAV, насколько я понял, даже не по всем измерениям существуют агрегаты. А считаются лишь по какой то статистически важной части по некоторым периодам. Зато прикольный механизм получается на уровне платформы: карточка контрагента, а в ней поле суммы продажи с проваливанием напрямую в таблицу детализации по номенклатуре. 1Сникам приходится все это тупо кодить :) | | |
| 110
- 09.08.2012 - 12:23
|
108-Lexusss > 1. Не соглашусь. Каждый случай надо рассматривать индивидуально. И легко можно получить такое, что в итоге пробежаться по движениям - существенно выгоднее в итоге, чем держать готовые цифре. В комплексе надо рассматривать ситуацию. А ответ "ХЗН" очень сильно уронил в моих глазах того самого преподавателя. Не профессионал он. 2. Извращение <> косяку - если это извращение не описано в документации, идущей с программным продуктам, то это - косяк. И никак иначе... Не стоит оправдывать необразованность писателей платформы... | | |
| 111
- 09.08.2012 - 12:25
|
109-Lexusss > Не стоит NAV приводить в пример какой-то хорошей реализации. При всей моей нелюбви к 1С - 1С-ка, как платформа, все-таки покруче будет. Ради прикола глянь, в каком виде в NAV хранится номер строки документа. По моему, 18 знаков после запятой - это некоторый перебор, на который не стоит равняться... P.S. Смотрел лет 8 назад. Может, сейчас и изменилось. | | |
| 112
- 09.08.2012 - 13:01
|
(110) 1. Полностью согласен. Вот держать продажи в ERP в готовой таблице - практически всегда приятнее пробежки. Потому как смотрит отчет руководство, а для самого пупер-супер генерального шефа время столь дорого, что ждать генерации отчета 30 секунд совершенно не приемлимо. С другой стороны, конечно, может быть терминал для кассового фронта, где эта выручка с детализацией до номенклатуры - ну совсем не нужна!!! 2. В документации лишь написано, что это работает. И оно действительно работает. Но вот за счет каких внутренних механизмов - это как раз и определяет уровень системного спецп. (111) Нууууу... GUID для ссылки - тоже не самая оптимальная вещь. Так что не надо позря гнать на NAV. :))))))) Один черт у сапов такие же агрегаты. Да ты сам сколько копал 7.7: таблица остатков по регистрам или корреспонденция проводок в бухитогах - это такие же агрегаты, прямо топчущие 3ю нормальную форму! ПЫСЫ: На теории БД ЕМНИП мы как раз и смотрели крайности, при которых полезно проводить нормализацию БД, а когда ее игнорить. | | |
| 113
- 09.08.2012 - 13:09
|
112-Lexusss > Так. Я уже не понял - за что спорим? :) Что не в определенных случая требуется денормализация? Даже спорить не буду, ибо согласен. Что в любом случае надо задачу всю видеть в комплексе, а потом думать над структурой и алгоритмами? Таки и здесь согласен :) | | |
| 114
- 09.08.2012 - 14:10
|
(113) Я высказал свое мнение исходя из того запроса, что ты показал: формируем что то в заказ-поставщику, имея на руках регистр продаж. Но при этом лезем еще и в таблицу движений товаров с дикими отборами! Итого: имеем нечто наподобии MRP, где данные извлекаются каким то жутким образом. Может быть, конечно, ты собрал статистику по БД, доказывающую что так будет оптимальнее. Но видя другие "творчества" в этом запросе, верится в это с трудом... 1. Вложенный запрос с объединением. SQL в этом случае не разворачивает внутренние сканы с внешними для оптимального использования индексов и минимизации количества слияния таблиц. Гораздо лучше это иметь в готовой таблице без объединения. 2. ЛЕВОЕ СОЕДИНЕНИЕ с справочником номенклатуры, и последующим жестким наложением условия ГДЕ на присоединяемую таблицу. Может, конечно, оптимизатор это и транслирует во внутреннее соединение, но это о многом говорит. 3. Наложение условие на номенклатуру в конце, а не во вложенном запросе. Вот здесь действительно надо угадать. Есть, конечно, шанс, что ты так обманываешь оптимизатор SQL от использования составных индексов, но верится с трудом... 4. Наложение условия на склад вне вирт таблицы Продажи.Обороты. В данном случае, без условия на период, это дейстивительно не важно. Но добавь сюда отбор по периоду - и это действительно станет архиважным! Вместо простого обращения к таблице оборотов будет сформировано еще прицепление к таблице движений, где вложенный отбор по складу играет очень положительное дело. 4... Можно еще придираться к мелочам. Но такой запрос мой строгий фейс контроль гарантированно не прошел бы. Чистый неуд с небольшими шансами на пересдаче. | | |
| 115
- 09.08.2012 - 14:16
|
114-Lexusss > Чуток поспорю по пунктам. 1. Со вложенными запросами с объединением скуль прекрасно справляется, включая распараллеливание. 2. Транслирует именно в INNER JOIN и даже не парится - проверено. А мне так запрос читать удобнее. 3. Тоже проверено на базах большого объема, что скулю так проще. У него больше вариантов для построения плана запроса, чем если бы я ему жестко указал. А он, зараза, в этом случае существенно умнее меня. Так что, про неуд ты погорячился :) | | |
| 116
- 09.08.2012 - 14:21
|
82-Sadovnikov > РегистрНакопления.Продажи.Обороты(, , , ) КАК регПродажи Не пробовал изменить на запрос просто к физ.таблице? Ну и как максимум - добавить измерение "Склад". | | |
| 117
- 09.08.2012 - 14:26
|
ой, мама... слона-то я и не заметил ты отбор накладываешь в самом конце ЛЕВОЕ СОЕДИНЕНИЕ РегистрНакопления.ОстаткиТоваров.Остатки(, Склад = &Склад) КАК регОстатки ПО (регОстатки.Товар = Продажи.Товар) вот это действительно, ужас | | |
| 118
- 09.08.2012 - 14:32
|
1. Какой скуль? У меня план запроса всегда строился четко - сначала вложенный, потом слияние с внешними таблицами. Где то мелкософты даже писали, что такого нормальное поведение оптимизатора и по другому не будет. У меня в основном SQL 2005. 2. Для абсолютного большинства человечества (включая и меня) - так НЕ ПОНЯТНЕЕ. Программист, пишущий для себя, а не по общепринятому стандарту для наследников, - это очень большой минус к разработчику. 3. Черт, даже интересно посмотреть на план выполнения запроса, написано строго против всех рекомендаций 1С и хрени, что мы изучали на теории БД. Неужто в T4 действительно впихнет слияние с T7 для отбора по Fld277. Или там настолько скучная статистика по этому полю? | | |
| 119
- 09.08.2012 - 14:34
| (116,117) Мальчик, хватит нести чушь и иди в школу! Тут взрослые дядьки ругаются. | | |
| 120
- 09.08.2012 - 14:35
|
116-android > Не пробовал изменить на запрос просто к физ.таблице? А смысл? Тот же шарик, вид сбоку получим. Скуль все равно только один раз группировать будет. Хотя, если честно, уже не вспомню, почему по таблице не сделал. 117-android > Где именно ты здесь отбор увидел? | |
Интернет-форум Краснодарского края и Краснодара |
