d-stream

Юзер с логином, хэшем пароля и мылом - это уже структура данных.
Подмножество юзеров - тоже структура (массив, список и т.п.) структуры из строчки 1

Вырвать руки "изобретателю" такого извращения. И забить его этими руками.
После этого прислушаться к nApoBo3 и осознать.

p.s. ещё во времена .dbf на изобретателей смотрели как на убогих.

С точки зрения нормальных форм - "это ненормально"
Но уж если так есть - то видимо костылить триггером. Либо бить ногами аффтора и приводить к человеческому виду.
Хотя подозреваю что это мельчайшая проблема из тех что там выявятся.

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

Ну например когда собеседующему непонятно как запрос собеседуемого работает, но он работает, результат получается верный и быстрее чем получилось у собеседующего)

p/s/ резюме с портфолио запросов - сразу фтопку)

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

Во всех остальных случаях ситуации "два выхода, один вход" и т.п. - достаточно регулярная ситуация.

Чуть облегчает картину, если есть разделение событий входа и выхода...

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

В общем:
- первый уровень выбор 100% корректных выборок сотрудник-день
- автокоррекция очевидных некорректностей типа два входа подряд в течение минуты
- ручная коррекция остального

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

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

p.s. без оконных функций такое считать тяжко

что за диалект?
в MS SQL либо "GO" если пачка, либо ничего не надо

Например анализ, сводные отчеты, показатели и прогнозирование

общее, простое как понять самому:
string test = $" то что скулю скармливается
и посмотреть значение test глазами или же при неочевидном скопипастить строку в консоль sql и получить от него описание ошибки.

Усложним вопрос: база живет на отдельном сервере, канал до которого 1мбит/с и попытаемся ответить на исходный вопрос в таких условиях.

Для более развитой фильтрации в виде набора нечто - стоит подумать о stored procedure, которая например будет получать кучку параметров фильтра

ну и в ней уже в простом случае единообразное

where
param1 is null or filed1=param1
...
and paramN is null or filedN=paramN

само собой параметр может быть неким энумоподобным который потащит за собой кучку предварительных запросов/вычислений (например только товары, которые были реализованы другим клиентам из этой же группы и т.п.)

В большинстве случаев интеллекта планировщика запросов хватит на то чтобы варианты с подзапросами, cte или having оказались по сути в плане выполнения идентичными. Поэтому тут на первый план скорее выйдет понятность/эстетичность самого текста запроса.

p.s. ну и заглядывая в будущее: вероятно когда-то критерий "от 5 до 10" может превратится в "от N до M", плюс "для только ... групп и только юзеров с признаками ..." -> запрос превратится в stored procedure с кучкой параметров и там возникнут свои нюансы хинтинга

Очень сильно зависит от диалекта.
В MS SQL - кучка вьюшек sys.* включая sys.tables (и sys.system_objects) - в общем достаточно легко средствами sql решается вопрос по выявлению таблиц, полей и их модификаци... включая даже тяжелые перекраивания pk
(собсно и ssms пользуется ровно тем же)

Первое что бросается в глаза - в селекте фигурируют поля, которые не участвуют ни в агрегации ни в группировке

select
    pr.pid,
    null as cid,
    pr.rcid as par_cid,
    pr.pname as name,
    sum(case when incoming = '1' then rec.quantity end) incoming,
    sum(case when incoming = '0' then rec.quantity end) outcoming,
    sum(case when incoming = '1' then 1 else -1 end * rec.quantity) balance
  from
    products pr
    inner join records rec on rec.rpid=pr.pid
  group by 
    pr.pid,
    pr.rcid,
    pr.pname

Так что стоит начать с первого селекта в with,
потом его же с union

и потом уже дальше

а потом у человека окажется две хонды...

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

пкм на любой таблице -> select top 1000 rows и медитируем над квадратными скобками