Руслан .

Может воспользоваться формулами на подобии тех что описаны тут:
https://mapgroup.com.ua/glavnaya/astronomicheskie-...

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

Можно для каждого датчика в оперативной таблице хранить две даты: дата начала интервала постоянства и дата окончания этого интервала. Это такой интервал в котором значение датчика не меняется.
Т. е. грузим текущие данные и если по датчику значение не поменялось, то просто изменяем дату окончания интервала на дату текущей загрузки, если значение датчика поменялось(отличается от сохраненного в оперативной таблице) , то текущий интервал выгружаем в архивную таблицу, а в оперативной добавляем новую(изменяем существующую) запись для датчика у которой дата начала и дата окончания будет равна дате текущей загрузки, а значение текущему загружаемому значению датчика.
Т. е. в оперативной таблице всегда количество записей равно количеству датчиков, а в исторической весь скоп предыдущих значений.
Это должно защитить от того, что с течением времени скорость работы с оперативной таблицей будет деградировать, от того что там будет расти число записей.
Если же нужно какой-то отчёт строить или выгрузку за период или за прошлые даты, то тут уже нужно будет работать с исторической таблицей и это будет уже не очень быстро, но такие операции обычно не требуется часто выполнять.

Так как данные грузятся раз в 3-4 дня, наверное не очень критично, что загрузка будет выполнять не мгновенно. Тут наверное проще в несколько этапов сделать: на первом проходе построить список идентификатор датчиков по которым значение не поменялось, затем по этому списку проапдейтить дату окончания интервала на дату текущей загрузки, затем по датчикам которые не попали в список перелить строки в архивную таблицу и наконец поменять для изменённый датчиков в оперативной таблице значение счётчика и даты начала и окончания интервала.
Всё шаги можно делать массово.

Может быстрее будет вместо delete написать:
SELECT * FROM D
WHERE numbering > 1;
И сохранить результат select во временную таблицу.
После этого грохнуть все эти строки и вставить уже по одному экземпляру каждой из временной таблицы.

Можно было бы добавить ещё одну таблицу групп с полями x и group. Заджойнить вашу table с новой таблицей по полю x и сгруппировать по полю group. В вашем варианте в какой-то момент case может стать очень сложным и не читаемым, адля добавления новой группы нужно всегда запрос дописывать, а это не гуд.

Мы аналогичную задачу решали так:
Создали таблицу в которую заноситься объект при подъеме его на редактирование. Все остальные пользователи при попытке редактировать этот объект, получают сообщение, что пользователь "такой-то" его уже редактирует и форма поднимается в режиме только для чтения.
Когда первый пользователь закрывает форму с объектом, из таблицы удаляется запись и объект сможет редактировать другой пользователь.

Иногда случались сбои (например дисконнект) и пользователь открывший объект на редактирование не мог корректно освободить редактируемый объект. В этом случае, если объект есть в таблице редактируемых, но процесс с его spid и именем пользователя отсутствует на SQL сервере , принудительно удаляем объект из таблицы редактируемых.

Без такого механизма периодически забивали несоответствия вида: "я поменял объект, сохранил, поднял его на просмотр, а он другой".

Можно через временны запрос попробовать:

WITH rates as
(SELECT rate, type, route_id, weight, volume
   FROM test_rates rs
  WHERE rs.dt_del IS NULL
    AND (rs.volume >= 300 OR rs.weight >= 50000))
SELECT rate, type, route_id, weight, volume
  FROM rates
 where rate = (select max(rate) from rates)