ponaehal

так работает?

UPDATE
    sales as s
SET s.plan_payment_date = (SELECT 
                                                       MAX(pay.payment_date) 
                                                   FROM 
                                                       payments pay
                                                   ,  payments_parts pp
                                                   WHERE pay.ID = pp.FK_payment
                                                          and s.ID = pp.FK_sale 
                                             )

Хотя сам бы за такое пальцы отрубил бы исполнителю )))

Count - групповая функция. Что бы запрос с Count работал, необходимо выполнение одного из следующих условий:
1. Count - только одно поле в списке выбора. T.е. SELECT count(*) from ...
2. Проведена группировка по всем атрибутам в списке выбора. SELECT fio, bdate, count(*) from tab group by fio,bdate.
Второй случай похоже покрывает ваши потребности.

На Вашем есте я бы еще посмотрел на аналитические функции COUNT(..) OVER (PARTITION BY ... ) имхо работать будет быстрее чем COUNT(..) GROUP BY..., но не понимая задачи не знаю насколько можно использовать в Вашем случае

1. Появление дублей в таблице лучше исключить в принципе, а не чистить постфактум. В целом это создаст более равномерное распределение данных по блокам БД и положительно скажется на общей производительности. Если дубли "плодит" какое то приложение, на которое Вы не можете повлиять, то рассмотрите возможность применения триггеров на таблице AccountItems .
2. В результате выполнения п.1. Ваш запрос станет проще. А если еще посмотрите в план запроса, добавите необходимые индексы, разобьете AccountItems на партиции, то есть шанс сделать совсем хорошо.

В принципе можно решить и "в лоб" но лень...

В порядке бреда:
Заполнить таблицу временными минимальными доступными временными интервалами в промежутке с 9 до 18 (создать расписание).
В вашем случае это будет 18 тридцатиминутных интервалов (всего 18 строк).
Далее, например, в случае резервирования на час, резервировал бы сразу 2 интервала.

А потом все сводится к банальному UNION ALL
SELECT <выводим интервал времени если при переводе часов в минуты остаток от деления на 30 равен 0>
UNION ALL
SELECT <выводим интервал времени если при переводе часов в минуты остаток от деления на 45 равен 0>
UNION ALL
SELECT <выводим интервал времени если при переводе часов в минуты остаток от деления на 60 равен 0>
UNION ALL
SELECT <выводим интервал времени если при переводе часов в минуты остаток от деления на 90 равен 0>

Если Oracle, то гуглите слова SELECT CONNECT BY PRIOR

В общем случае нельзя сказать однозначно.... в целом индексы предназначены для ускорения доступа к записям, в т.ч. при удалении и изменении. Но индекс, это отдельная структура на ведение которой СУБД тратит свои ресурсы. Например, при вставке данных в таблицу на которой "висит" 5 индексов, идет еще пять вставок в каждый из этих индексов. Причем вставить новую строку в индекс гораздо сложнее (с точки зрения ресурсов СУБД, возможно в зависимости от используемой СУБД) чем в таблицу, т.к. сначала необходимо найти место куда эту строку вставлять (сейчас говорю о наиболее распространенных b-tree индексах) и ссылки блоках индекса.
Более того, говорить о том, что индекс ВСЕГДА ускоряет доступ к записям - тоже неверно. Все зависит от вашего запроса и способа доступа к данным. Если данных для запроса достаточно в индексе, то СУБД выгребет данные вообще без доступа к таблице. Это во многих случаях (но не всегда :)) будет сильно быстрее чем извлечение данных непосредственно из таблицы. Если в запросе извлекается данных больше чем содержит индекс, то СУБД будет (если ее заставить) сначала обращаться к индексу для того что бы найти адрес строки в таблице, а затем полезет в таблицу и извлечет необходимые данные). Будет ли это быстрее чем просто искать по таблице? - во многом зависит от того сколько % записей должен вернуть запрос. Обычно рекомендация такова: если запрос должен вернуть больше 15-20% строк таблицы, то использование индексов нецелесообразно... Но даже тут есть 100500 тонкостей и особенностей.... В общем в этом вопросе мир тоже не делится на белое и черное... как то так...

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

Говорю про Oracle, но подозреваю во всех БД примерно так же
Раз и навсегда отсортировать данные не получится. Данные в таблице неотсортированы. Можно это сделать искусственно. Перенести данные в другую таблицу, потом данные в исходной таблице удалить и залить из второй в нужном порядке. Но смысла от этого немного - когда кто-нибудь еще добавит данные в эту таблицу, ваша сортировка поедет. В общем случае, гораздо правильнее воспользоваться индексом (в нем данные осортированы) и следить что бы он использовался в запросах.

Погуглите "иерархический запрос"
например так: https://urvanov.ru/2017/05/28/%D0%B8%D0%B5%D1%80%D...

по первому вопросу может сработать (В зависимости от используемой БД или стандарта SQL):

select t1.* from table1 t1
INTERSECT
select t2.* from table2 t2

Насколько я помню молодость HAVING фильтрует по значениям агрегаторов (SUM, MAX и т.д.), а в вашем случае нужно просто добавить фильтр в условие WHERE .... AND group in (1,2)