Вход | Регистрация
 
1С:Предприятие :: 1С:Предприятие 7.7 и ранее

v7: Знатокам чорных запросов - фильтрация по "группировочному" условию..?

v7: Знатокам чорных запросов - фильтрация по "группировочному" условию..?
Я
   Злопчинский
 
17.03.21 - 16:03
задачка.
есть оборотный регистр. допустим Регистр.Заказы
Измерения: Заказ-Номенклатура
есть ресурс План (сколько клиент заказал шт)
есть ресурс Факт (сколько склад собрал шт)
есть движения которые по (заказ,номенклатура) двигают отдельно ПЛАН (в плюс)
есть движения который по (заказ,номенклатура) двигают отдельно ФАКТ (пусть тоже в плюс)
.
задача - получить в результате выполнения запроса ТЗ вида
Заказ-Номенклатура-НеВыполнено, где
НеВыполнено (План-Факт) > 0
.
или на крайняк кортежи типа
Заказ-Номенклатура-(План-Факт)-НадоУдалить, где НадоУдалить=1 Когда (План-Факт)<=0

.
Получится ли такое сделать чорным запросом?
   Злопчинский
 
1 - 17.03.21 - 16:07
Максимум чего добился В ЗАПРОСЕ получение кортежей
(Заказ,Номенклатура,(План-Факт),НадоУдалить) где НадоУдалить=1 только если (План-Факт)=0
   Злопчинский
 
2 - 17.03.21 - 16:11
Улучшил
Максимум чего добился В ЗАПРОСЕ получение кортежей
(Заказ,Номенклатура,(План-Факт),НадоУдалить) где НадоУдалить=1 если (План-Факт)<=0
/
но вот исключить такие строки чтобы не выдавались как результат запроса - пока никак...
   Злопчинский
 
3 - 17.03.21 - 16:13
|Период с ДатаН; 
    |Без итогов;
    |
    |Заказ = Регистр.Заказы.Заказ;
    |Номенклатура = Регистр.Заказы.Номенклатура;
    |
    |План = Регистр.Заказы.Заказано;
    |Факт = Регистр.Заказы.Отобрано;
    |
    |Функция КоличествоПлан = Сумма(План);
    |Функция КоличествоФакт = Сумма(Факт);
    |Функция КоличествоНаОтбор = Сумма(План-Факт);
    |Функция НадоУдалить = Сумма(1) Когда ((Запрос.КоличествоНаОтбор<=0));
    |
    |Группировка Заказ Без Упорядочивания;
    |Группировка Номенклатура Без Упорядочивания Без Групп;
    |";
Запрос.Выгрузить(ТЗ,1,0);
   Волшебник
 
4 - 17.03.21 - 16:26
Разве ещё не все клюшечники перешли на прямые запросы?
   Злопчинский
 
5 - 17.03.21 - 16:43
(4) ну. у кого объемы больше - те перешли. или терпят.
у меня объемы на таких проектах - несущественные, регистры укладываются в отведенные 16 млн записй даже в ДБФ за несколько лет. Поэтому осовил мало-мало самые простейшие...
   Злопчинский
 
6 - 17.03.21 - 16:51
(4) а там где на складах большие объемы - там я не программлю, там я в других ипостасях проекты делаю ;-)
   Злопчинский
 
7 - 17.03.21 - 16:52
И все эти клюшки сейчас больше на Хобби похоже у меня ;-)
   Злопчинский
 
8 - 17.03.21 - 16:52
В итоге - по существу сабжа кто-нить прокомментиует, или клюшечников не осталось вменяемых?
   Arbuz
 
9 - 17.03.21 - 17:52
чорные запросы -зло
   Ёпрст
 
10 - 18.03.21 - 02:47
(0) в лучшем случае, выйдет только через обращение к итогам запроса:

|Условие(Запрос.КоличествоПлан-Запрос.КоличествоФакт>0);

но.. тебе нужен примитивный select + group by + having ....это в разы проще и быстрее
   Ёпрст
 
11 - 18.03.21 - 02:48
И Чебур, кто у тебя аккаунт угнал ? Перелогинься
   Злопчинский
 
12 - 18.03.21 - 07:07
(11) Не злобствуй!
   Злопчинский
 
13 - 18.03.21 - 07:09
(10) была у меня такая мысль, но не дошел до нее окончательно (ранее использовал подобное).
"select + group by + having ....это в разы проще и быстрее" - это для полиглотов.. а я консерваториев не кончал ;-) это уже позжее если бюджеты будут - тогда оптимизировать, сейчас надо функциональность требуемую обеспечить...
.
Спасибо.
   Вафель
 
14 - 18.03.21 - 07:32
так все равно же перебором запрос выводить, там и удалить можно
   Злопчинский
 
15 - 18.03.21 - 08:25
(14) куда выводит? зачем выводить? никуда не выводить не планируется..
хочется получить таблицу максимально очищенную от "лишних" данных. а потом эту таблицу куртить/фильтровать/сортировать, но обработкой одиночных записей уже не заниматься - так тупо удобнее, иначе в куче мест придется костылей ставить н апропуск ненужных строк, на проверку а есть ли в подмножестве таблицы ненужные строки и прочее.
   Mikeware
 
16 - 18.03.21 - 09:01
(15) "куртить" (и гансить) удобнее ИндексированнойТаблицей. Там же есть и фильтры, и группировки..
Ну есть же удобные инструменты - зачем пользоваться заведомо неудобными? "чтоб служба медом не казалась?"
просто надо принять как данность, что 1с++ и Формекс - это "джентльменский набор клюшечника", и пользоваться.
   Злопчинский
 
17 - 18.03.21 - 17:02
(16) Убедил! сегодня вечером часть перепишу на ИТЗ. а то выдершгивать из плоской таблицу частную, обрабатывать ее, а потом из нее сливать скорректированные данные обратно в большую - затрахался уже
   Ёпрст
 
18 - 18.03.21 - 18:22
(17) ну или родить запрос человеческий..
   Злопчинский
 
19 - 18.03.21 - 18:28
(18) ниасилил. если бы один запрос человеческий - то еще с помощью спецов получилось бы. А так - приведенный - всего лишь один из... там еще куча других таблиз с итогом по этому запросу скрещивается и обрабатывается. По уму как я вижу там процентов 50% кода надо запрсоами делать, но я ж не могу всю работу на когото переложить. да еще и забесплатно ;-)
   Злопчинский
 
20 - 18.03.21 - 18:53
(10) кстати, неа...
в таком виде
|Условие((Запрос.КоличествоПлан-Запрос.КоличествоФакт)>0);
.
запрос из (3) вообще неверные дает вообще. Количество план - норм, а количествоФакт вообще нулевое получается и итог кривой.
потому видать что
запрос.КоличествоФакт примеяется к отбираемым записям, а План и Факт - отдельные записи по регистру и в каждой записи КоличествоПлан получается = 0... и условие отсеивает все фактовые записи
   hhhh
 
21 - 18.03.21 - 18:58
(19) ну сделайте регистр остатков. У него всё это на уровне платформы вшито, надо удалить, не надо удалить, он всё делает сам. Как-то получается, что вы через задний проход пытаетесь вытащить остаток из оборотного регистра.
   Злопчинский
 
22 - 18.03.21 - 19:35
(21) пофиг. можно сделать на регистре остатков. Но кроме Остатка (План-Факт) мне нужен Оборот ПЛАН - и как предлагаешь тянуть его их регистра остатков - да, Приход и Расход - но в оборотном регистре это хоть как-то оптимизировано...
   Злопчинский
 
23 - 18.03.21 - 19:35
(21) на самом деле не суть важно пока, объемы небольшие
   Злопчинский
 
24 - 18.03.21 - 19:40
(16) нет, не удобнее.
Первый же "глюк", с которым столкнулся (знал-забыл), но вспомнил походу...
ИТЗ.ЗагрузитьЗапрос(Запрос,1,0).
При разработке и отладке много и часто пользуюсь Универсальной печатью ТЗ,
ПечататьИТЗ оно не умеет, это понятно, сделал обертку, если на вход ПечатьТЗ(ИТЗ) - тогда ИТЗ перегружаю в ТХ и вызываю уже ПечатьТЗ(ТЗ). Только незадачка... в ТЗ все выгружается нетипизированными колонками. И все процедуры и прочие феньки, которые можно делать опираясь на типизированность колонок - идут в топку, в данном случае - автосуммирование колонок ТЗ по числовым колонкам... и все.. ахеренное удобство накрылось медным тазиком.
.
   Злопчинский
 
25 - 18.03.21 - 19:41
как теперь выводить отладку? писать быдлокод типа если ИмяКолонки = "ЧтоТо" тогда считать что тип колонки число?
   Злопчинский
 
26 - 18.03.21 - 19:43
фича в (24) сразу напрочь убивает скорость контроля/отладки при тестировании.
.
есть что-то аналогичное универсальной ПечатьТЗ(ТЗ), чтобы печатать ИТЗ не заморачиваясь частностями конкретной ИТЗ?
   Злопчинский
 
27 - 18.03.21 - 19:48
Блин, и всего-то надо было что для начала в ИТЗ: Группировать и все...
Теперь проще от ИТЗ отказаться на этапе разработки и тестирования, нарисовать собственную группировку ТЗ (пострадав в скорости выполнения, но благо это не в миллионном цикле) и пролоджать работать на ТЗ отлаживаясь и тестируясь. а на ИТЗ переходить после запуска в продакшн, когда все отлажено будет...
   Злопчинский
 
28 - 18.03.21 - 19:49
..Или я чего-то не знаю хитростей ИТЗ?
   Злопчинский
 
29 - 18.03.21 - 20:27
даже рисовать не надо собственную группировку - уже все написано до нас...
   Злопчинский
 
30 - 18.03.21 - 23:18
Попутно обнаружил такую штучку занятную
Допустим,есть строка сортировки ТЗ, типа

СтрокаСортировки = "Контрагент-,Направление+,Маршрут*"
если по этой строке сделать свертку ТЗ.Свернуть(СтрокаСортировки,) - то знаки сортировки + и - - никак не мешают свертке, а вот зна к * - в итоговй ТЗ соответсвующей колонки не будет...
 
 Рекламное место пустует
   Ёпрст
 
31 - 18.03.21 - 23:38
(27) Лучше один раз разобраться, чем лепить      медленные решения на обычной ТЗ.
В ИТЗ - там всё просто как грабли.
   Злопчинский
 
32 - 19.03.21 - 00:18
(31) я в курсе и согласен. но нетипизированность ИТЗ - мешает (пока)
   Mikeware
 
33 - 19.03.21 - 09:08
(19) "лучше день потерять - а потом за час долететь"©
   Mikeware
 
34 - 19.03.21 - 09:11
(26) валялось где-то - печать сгруппированной ИТЗ (ну, чт-то типа дерева). поможет?
   Ёпрст
 
35 - 19.03.21 - 09:14
И..был еще Класс.ИтогиПоГруппировкам от А.Диркса
   Злопчинский
 
36 - 19.03.21 - 11:38
(34) а то! конечно, пригодится.
   Злопчинский
 
37 - 19.03.21 - 11:54
(31) ага, как же.. в ТЗ все просто как грабли. если что-то "не работает" - значит тупо "не работает" и все понятно, - ищется на раз.
в ИТЗ - хз... пока не наблатыкаешься... то там надо индекс указать, то здесь, то отсортировал, при обходе нломается потому что "количество" меняшь, которое оказывается индекс входит когда раньше сортировал.
   Злопчинский
 
38 - 19.03.21 - 11:54
и ТЗ.сортировать(<Колонки>,<ДокумПоДате>)
как в ИТЗ сделать чтобы доки по Хронологии сортировались, как в типовой ТЗ?
   Mikeware
 
39 - 19.03.21 - 12:15
(38) ну создай колонку с моментом документа.
   Злопчинский
 
40 - 20.03.21 - 14:44
Продолжаю искать аккаунт ;-)
.
вот, допустим, в чорном запросе есть переменная запроса (нужна в результирующей выборке)
|КратностьОсновнойЕдиницы = Регистр.Заказы.Номенклатура.ОсновнаяЕдиница.Коэффициент;
.
в условиях и группировках запроса "КратностьОсновнойЕдиницы" не используется.
.
Вопрос:
КратностьОсновнойЕдиницы - вытягивается из базы для ВСЕХ ПЕРЕБИРАЕМЫХ записей регистра
или только для тех записей, которые удовлетворяют условиям запроса?
   Вафель
 
41 - 20.03.21 - 15:37
в чорных запросах вроде веачале все выберем, а затем наложим фильтр
   Злопчинский
 
42 - 20.03.21 - 17:36
(31) Убедил, делаю сейчас, используя ИТЗ по некоторым моментам
   Mikeware
 
43 - 21.03.21 - 20:08
(40) да, строится дбф-ка по всем полям запроса, вытягивается на клиента, и уже там фильтруется - вычисляется.
   Злопчинский
 
44 - 21.03.21 - 20:45
(43) как-то совсем нехорошо... а почему условия на "сервере" не могут считаться?
навскидку и не вспомню .. - это только если условия могут применяться к уже сгруппированным/сконсолидированным числовым данным - а такое в условиях запроса может быть?
   Злопчинский
 
45 - 21.03.21 - 20:46
Условие из (2) - например, вообще нифига правильно не считается, не применяется к "сгруппированным/просуммированным" числам на уровне группировок...
   Злопчинский
 
46 - 21.03.21 - 20:47
поправка - .."условие из (20).."
   Mikeware
 
47 - 21.03.21 - 21:07
(44) так создал БоГ (БОрис Георгиевич) :-)
Видимо, консистентности ради. Ну и  вообще, выбирать из дбф... я по заветам ВилдХаре вроде начинал разбираться, но сразу плюнул и перелез на прямые.. прикинь, вот совсем черных не знаю, кроме того, что конструктором построить можно.
   Злопчинский
 
48 - 21.03.21 - 23:05
(47) ну, тут я думаю что большиснтво тех чорных запросов что япишу/использую - я бы и на прямых осилил ввиду их простоты и линейности.. но.. объемы не напрягают и поэтому использование прямых ну крайне эпизодическое у меня


Список тем форума
Рекламное место пустует  Рекламное место пустует
ВНИМАНИЕ! Если вы потеряли окно ввода сообщения, нажмите Ctrl-F5 или Ctrl-R или кнопку "Обновить" в браузере.