Akina

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

Возможное решение - UNION ALL двух запросов. Первый - получающий список полей таблицы из INFORMATION_SCHEMA.COLUMNS в виде CSV, второй - собственно показанный запрос. Поскольку UNION ALL не перемешивает выходные записи, получится вроде бы то, что нужно.

Однако есть грабли. Невидимые вычисляемые столбцы. Они будут присутствовать в списке полей, но не в наборе данных.

См. fiddle

Можно, конечно, использовать какую-нибудь дурь типа

WITH cte ( поля ) AS (
    -- твой запрос
    )
SELECT [ поля ] FROM cte
UNION ALL
SELECT NULL, ... , NULL WHERE NOT EXISTS (
    SELECT NULL FROM cte
    )

Но, право слово...

а что делать с реляционной бд

А ничего. НЕ хранить ежедневные итоги. Только приходы и уходы. И самая первая запись - только приход (начальный баланс), если начинаем не с пустой кассы. А сумму с накоплением считаем непосредственно в запросе, в тот момент, когда потребовался отчёт.

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

насколько оптимально такое решение?

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

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

Актуализация данных таблицы (точнее, её полный пересчёт) выполняется из триггерной процедуры на каждое событие изменения любой из используемых в запросе таблиц, если изменение связано с вашей системой (заодно можно выпилить оттуда не связанные с приложением записи). Поскольку работа по изменению указанных данных достаточно редкая по сравнению с запросами на получение данных, такая схема может дать определённый профит. Однако, поскольку процесс предусматривает полную очистку таблицы и заполнение её с нуля, следует избегать интерференции со стороны двух конкурентных процессов изменения. Для полной гарантии любые изменения следует проводить в изолирующей транзакции.

Хотя как по мне, следует отделить систему безопасности Постгресса от авторизации в приложении. Мнение по данному вопросу от Everything_is_bad в комментарии - это не сарказм, а весьма правильное замечание.

Ну вообще-то хранение изображений в полях базы данных считается антипаттерном... а по сути - это вообще худшее из возможных решений.

Наилучшее решение - файлы хранятся в FileTables либо FILESTREAM, а в таблице лежат ссылки на них. Что приятно - при этом не надо распыляться с безопасностью, за ней следит SQL Server.

Сравнение параметров для хранения больших двоичных...

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

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

LIKE в принципе не пригоден для указанной операции. Это чисто текстовый оператор. В частности, он безусловно применяет к обоим операндам регистронезависимый collation - в этих условиях сравнение БИНАРНЫХ строк способно давать весьма неожиданные эффекты.

Если надо работать именно с бинарными строками - всё плохо. В MySQL нет нормальных функций для работы с ними.

Для решения задачи рекомендую преобразовать бинарную строку в шестнадцатеричное представление, укоротить до 40-символьного (что соответствует 20-байтовому бинарному значению), преобразовать обратно, и сравнить.

WHERE CONV(LEFT(HEX('$entered_hash'), 40), 16, 10) = correct_hash

К тому же такое условие SARGable.

PS. В выражении

WHERE '{value1}' = '{value2}' OR '{value1}' LIKE '{value2}%'

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

SELECT *
FROM Author
WHERE NOT EXISTS (
    SELECT NULL
    FROM Book
    WHERE Author.Authorld = Book.Authorld
      AND Book.PublishDateTime >= CURRENT_DATE - INTERVAL 2 YEAR
    )

SELECT table1.*, 
       EXISTS ( SELECT NULL
                FROM table2
                WHERE table2.table1_id = table1.id
                   AND table2.date = @needed_date
                ) AS row_exists
FROM table1

Если точная дата внутри месяца неизвестна, то

WHERE table2.date BETWEEN @needed_month_1st_day AND @needed_month_last_day

Для решения задачи набор искомых значений должен быть (синтетическим) набором записей, который используется в источнике данных запроса.

Ну вариант первый - это просто хранить данные за день, а всякие укрупнения считать в момент необходимости.

Вариант соответственно второй - считать все укрупнёнки в момент записи текущих данных. Удалять/чистить лучше отдельной эвент-процедурой, если старая укрупнёнка недельку полежит, никто не помрёт. Вопрос отдельных таблиц под разные укрупнёнки - только если их структура различна в зависимости от периода, иначе одна таблица и поле маркер - диапазон периода записи.

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

??? Какое ещё "поле"? может, запись? ну так для этого существует INSERT ... ON DUPLICATE KEY UPDATE Statement.
А триггеры - они для дела, а не для баловства..

MS Access не имеет функции групповой конкатенации.

Проблема решается путём создания пользовательской функции и использования её в запросе.

Function group_concat(category As String) As String
With CurrentDb.OpenRecordset("SELECT [Цех] FROM [Имя таблицы] WHERE [Продукция] = '" & category & "'")
    group_concat = ""
    .MoveFirst
    While Not .EOF
        group_concat = group_concat & "," & ![Цех]
        .MoveNext
    Wend
    .Close
End With
group_concat = Mid(group_concat, 2)
End Function

Поскольку пользовательская функция - скалярная, и не агрегатная, её нужно оборачивать какой-либо агрегатной функцией.

SELECT [Продукция], MAX(group_concat([Цех])) AS [Цех]
FROM [Имя таблицы]
GROUP BY [Продукция];

PS. Конечно, функцию можно сделать более универсальной, передавая в неё имена таблицы и полей, а также маркер типа данных поля категории.

---
Ну или взять готовую DConcat() от Patrick G. Matthews: https://www.experts-exchange.com/articles/2380/Dom...