Какая база данных лучше всего подходит для хранения и расчета?Да практически любая.
Должно ли это вычисляться на стороне базы данных или лучше сделать выборку и вычислить на стороне бэкенда (ужас при большом количестве клиентов)?С данными работает сервер баз данных. Всё, точка. Исключения - есть, не даже сказать что они редкие, но не на этом уровне.
Программное обеспечение должно вычислить, какие клиенты будут обслуживаться в определенную дату в будущем.Должна существовать определённая разумность. Да, можно рассчитать на сто лет вперёд - но зачем? это даже на экране не поместится, да и если бы поместилось - оно просто не воспримется. А расчёт на вменяемый период - это достаточно легко и быстро.
...
Должен ли это быть предварительно рассчитано и как это сделать на неопределенный период времени?
из которых 1ms - это freeing items и cleaning up
На MySQL сразу выяснилось, что джоинить квартиры (а также корпуса и секции) к жилым комплексам астрономически долго, просто потому, что квартир много, а комплексов мало. Гораздо быстрее делать наоборот - брать квартиры и присоединять к ним жилые комплексы, а также все остальные сущности по наличию.
Но в PostgreSQL 12 GROUP BY так делать не умеетПостгресс делает правильно. А вот MySQL - "какой бы бред не получился, лишь бы работало". Распечатайте крупно, повесьте на стену и заучите - Звезда используется только в COUNT(*), вол всех остальных случаях поля перечисляются все, которые нужны, поштучно, по одному. Отступать от этого правила можно лишь тем, кто чётко понимает последствия.
получается такой запрос
Угу. Только всё с точностью до наоборот. Сначала генерим все даты нужного периода, а потом отбрасываем те, что не соответствуют.
SQL работает с множествами, а не с потоками. Итерации и переборы - это не к нему.