Class Std Бюджет порта (PSE) Макс. мощность устройства (PD)
0 802.3af 15.4 W 0.44 - 12.95 W
1 802.3af 4.0 W 0.44 - 3.84 W
2 802.3af 7.0 W 3.84 - 6.49 W
3 802.3af 15.4 W 6.49 - 12.95 W
4 802.3at PoE+ 30 W 12.95 - 25.5 W
Нет. user_comments - лишняя. Ну право слово, не пишут же юзеры комментарии коллективно? А если комментарий не может относиться сразу к нескольким товарам, то и products_comment тоже лишняя.
Чудес не бывает. Запрос - детерминированный. А потому есть лишь одно предположение - MySQL от кода при запуске на сайте получает не такой текст запроса, какой ты видишь в дампе.
Посему рекомендую - включить временно General Log, выполнить код на сайте, и посмотреть, какие запросы были получены сервером от кода.
Бизнес-процессы в магазине могут быть организованы по-разному. Соответственно и схемы могут быть разные.
Выкладывайте описание бизнес-процесса и выполненный анализ предметной области - будем смотреть, соответствует одно другому и составленной схеме или нет.
Навскидку могу сразу сказать, что схема косая. Денормализована таблица адреса. Лишняя связь между товаром в магазине и товаром в заказе (Вы путаете pattern и entity). Хранение цены во FLOAT, а даты и времени в отдельных полях - тоже ошибка. Это то, что видно сразу.
lag() и lead() берут только по одной строке, а разрыв между активностями может быть больше
Вообще-то запрос должен включать опорную таблицу календаря, содержащего все даты периода (используем генератор или рекурсивный CTE). А создание добавляемых записей лучше выполнять не с помощью оконных функций, а латеральным джойном имеющихся данных к календарю.
Какой смысл делать SELECT *, если проверяется только существование записи? Гораздо разумнее выбирать какой-нибудь литерал, скажем, SELECT 1 или даже SELECT NULL.
Классы описаны в стандартах: