[mazzy]

Цитата:

Сообщение от Ruff

Вот, для затравки, первые наброски:

    queryRun = SimpleQueryBuilder::newQuery().	// здесь параметром вполне может выступить querystr(MyAOTquery)
        select  (tablenum(CustTable)).
                groupBy     (fieldnum(CustTable,        AccountNum)).
                groupBy     (fieldnum(CustTable,        PartyId)).
            join (tablenum(CustTransOpen)). 
                relations   (true).
                sumField    (fieldnum(CustTransOpen,    AmountCur)).
        parent().
            join (tablenum(CustGroup)).
                relations   (true).
                mode        (JoinMode::ExistsJoin).
                range       (fieldnum(CustGroup, PaymIdType),  paymIdType).

        queryRun();

    while (queryRun.next())
    { ... }

Пример - рабочий, запрос - просто иллюстрация, код SQB пока не публикую, ибо сыр и мало что умеет.

Удобно ли? Или те же буквы, только в профиль?)

Атличный пример!

mode        (JoinMode::ExistsJoin).

поставлен на группу клиентов, которая в целостной базе всегда есть - в стандартном функционале включен validate.
и не поставлен на открытые проводки, которые вполне штатно могут отсутствовать.

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

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

прекрасная ошибка - суммирование AmountCur без группировки по валютам. запрос вернет сумму рублей с долларами, еврами, гривнами, тугриками и остальными валютами.
правило: если выполняется агрегирование по AmounCur, то группировка по валютам является обязательной. именно такая информация и должна присутствовать в пресете. подумайте о таких логических взаимосвязях только один раз - при создании пресета, а потом пусть программа думает и предупреждает. тогда и будет "удобно".
))))

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

а упрощение синтаксиса... ну, да... оно конечно тоже приятно. )))

==========================
добавил, подумав над запросом:
PaymIdType есть в группе, а есть в самом клиенте. кроме того, он есть в paymMode, который присутствует в проводке.
мне кажется, что фильтрация по полю PaymIdType в группе - всегда логически ошибочна.
мне кажется, что нет случаев, когда фильтрация по полю PaymIdType в группе была бы логически оправдана.

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

а упрощение синтаксиса... ну, да... оно конечно тоже приятно. )))

=================
трудозатраты:
время последней правки 13:00 - время создания готового поста с первоначальным текстом 12:25 ~= 0:35 минут потрачено на обдумывание логики запроса
сам пост написан минуты за 2 )))

и это очень типичное соотношение трудозатрат между логикой и синтаксисом.