ThunderCat

Нет, если наружу база не смотрит, а обычно так и есть. И это нормально. На самом деле это обычно не нужно. С чего вдруг понадобилось так активно работать на хостинге с базой? Локально создаете бд, экспортируете, на хосте поднимаете. Ну или если это более-менее нормальный движок с поддержкой миграций вообще через них.

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

Подскажите пожалуйста, что я делаю не так

Не занимаетесь отладкой, а занимаетесь гаданиями.

и где может быть моя ошибка.

В произвольном месте. По этому проверяют по порядку
1) Что передается в data в яваскрипте (console.log)
2) Что передается в на сервер (смотрим нетворк браузера)
3) Что получили на стороне сервера (var_dump и тот же нетворк, смотрим ответ аякса)
4) Проверяем запрос, и с таким заданием плейсхолдеров бинд не нужен:

$stm = $this->db->prepare($sql);
$stmt->execute($params);

JSON_OBJECTAGG

селект, джоины, вэа, энд, ор...

Смотри ошибки в логах
Проверяй содержимое переменных
Проверь запрос руками из консоли или из пхпмайадмина
Думай головой

По уму вы должны были дать кейс сенситив коллэйшн для поля, по которому собираетесь делать кейс сенситив выборки. Как "кривое" решение можно использовать BINARY, как написал Илья

Дополню и поправлю ответ Дмитрий, с первым вариантом все понятно и так, единственное уточнение - это максимально не гибко и в реальных проектах считается плохой практикой. Если завтра в данную структуру понадобится добавлять новые сущности - вся структура идет по бороде и вы должны будете все перестраивать.

Со вторым вариантом все более-менее неплохо, единственное что не упомянуто - в базовой таблице нужно хранить еще и тип пользователя, и join при такой структуре теряет смысл, так как вам в любом случае придется выполнять 2 запроса - один чтобы авторизироваться, другой чтобы получить данные из нужной таблицы, исходя из типа пользователя, ну или заморачиваться с достаточно сложными запросами на основе ифов и тд, что становится еще хуже с добавлением дополнительных сущностей. В идеале еще должна быть справочная таблица типов пользователей, но это уже нюансы.

Ну и есть 3 вариант, который в данном КОНКРЕТНОМ случае подходит меньше, но в целом более подходит под смысл - общая таблица сущностей с базовыми параметрами + множество атрибутов для подгрупп сущностей. Называется EAV.

селект имя, сум(часы) часы
фром имена и
лефт джоин тайм т
он и.ид = т.емплои_ид
груп бай т.емплои_ид
ордер бай часы деск лимит 3

как то так...

Наиболее затратное по времени выполнения это расчет остатков за весь период на указанную дату в разрезе по номенклатуре.

1) Это ваше предположение или вы делали замеры производительности запросов и кода?
2) Если производительность действительно проседает, то каким образом у вас происходит вычисление? SQL с агрегацией и каунтом?
3) Сколько строк в таблицах выборки?
4) Что показывает explain?
5) Индексы?

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

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

trigger

Как вариант я думал написать говнокод, который на PHP преобразует первоначальную дату диапазона из 26.05.2020 в "2020-05-26 00:00:00" а конечную дату в "2020-05-27 23:59:59" а потом сравнивать, но помоему это какая-то дичь.

То есть по вашему преобразовывать ВСЕ строки таблицы для сравнения в формат НЕ ПОДДЕРЖИВАЕМЫЙ интерфейсом бд это ок, а 2 значения привести в стандарт - не комильфо...

Обратите внимание на ответ Rsa97, Даты сравниваются как строки, по этому и сравнение идет именно в таком формате, от года к дате. Ваше преобразование делает строки вывернутыми по смыслу, то есть сортировка идет по дате дня, год "как бы вообще не учитывается".