Akina

ANY вместо IN?

CREATE OR REPLACE FUNCTION get_count(VARIADIC ids integer[]) RETURNS int AS $$
	SELECT COUNT(*) FROM device 
	-- WHERE device.id IN (ids)
	WHERE device.id = ANY (ids)
$$ LANGUAGE SQL

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

ПС. роутер используется в случаях, когда адрес назначения вне локального диапазона

Да, лучше использовать конструкцию

insert into foo (entity_id, count)
values (8, 1)
on duplicate key update count = count + 1;

В MySQL 8.0.2 и выше GROUPS - зарезервированное слово. Если хотите так назвать таблицу или колонку, надо брать название в обратные апострофы - `groups`.

Как вариант использовать структуру CASE в самом запросе.

Предлагаю рассмотреть переход на специальный тип данных: MS SQL: hierarchyid — иерархия по-новому. Также: Иерархические данные.

Рекурсия, пример D.

Проверять, что результат запроса содержит данные о товаре. Если не содержит - показывать пользователю об этом сообщение.
Выполнение запроса с WHERE id = 'несуществующее значение' не является ошибкой само по себе, это вполне нормальная ситуация, которую нужно просто обрабатывать в коде.

Но уверен есть решение элегантнее и разумнее)

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

UPD. С числом ошибся. Я имел в виду первые 3 нормальных формы. Кто хочет большему количеству форм соответствовать - пожалуйста

Или это ок?

В текущем варианте - ок.

1. Подумать.
2. Написать код.

А если серьёзно, задача сводится к разложению числа на заданные слагаемые. Это гуглится.
Один из способов (необязательно самый быстрый) - рекурсивное разложение. Упрощенно, перебираешь все Ai меньшие N. Выкидываешь это Ai из рассматриваемого набора, и затем рекурсивно пытаешься составить число (N - Ai) из всех Aj, меньших или равных Ai (так как большие слагаемые ты уже рассмотрел).
Углубляясь в рекурсию, рано или поздно ты наткнёшься на одну из двух ситуаций:
а) среди Aj есть число, равное искомому. Решение найдено, осталось размотать рекурсию обратно и собрать в кучку использованные Ai.
б) нет ни одного Aj, меньшего или равного искомому числу. Решения нет.
В твоём случае будет ещё случай в) Сумма всех Ai меньше N. Решения нет, заплатить не удастся. Это можно проверить вообще сразу.

Реализовать будет проще, если отсортируешь Ai в порядке убывания. Тогда вместо удаления Ai из списка слагаемых достаточно будет выбрать индекс i, с которого будешь начинать рассмотрение слагаемых - все элементы до i-го либо слишком велики, либо уже были рассмотрены и не пригодились.