Gregory's ServerИнтересно, а можно ли это сделать проще чем селект с двумя подзапросами....
|
32 comments
 Капец, они убрали кнопку лайкнуть ответ Внезапно, мой написанный из головы запрос с двумя подзапросами заработал с первого раза....шта...  Запросики кажется есть. Страшненькие немного, но щитоподелать если так работает фильтр по максимальному значению в SQL Хорошо что я решила сначала описать результат а потом уже писать код Получается, три часа работы в состоянии ьеьеьеьеьеь нужны были лишь для того, чтобы задаться тем самым вопросом «а что если» и в итоге добавить ещё одну сущность и переписать все запросы... Кажется я задаю слишком много вопросов. С другой стороны, вроде логичных...но теперь возникшую сложность надо как-то решать, а я ьеььеьеьеьее.... Теперь селекты станут ещё более многоуровневовые, видимо...мозг просыпайся.... ...и вылез граничный случай, который крайне редкий но если я его проигнорирую то меян будет бесить его возможность аааааааааааааааааа Я не хочу воспроизводить гит в реляционной базе но я не знаю как ещё корректно обойти этот граничный случай... Я потерялась в селектах и группировках и вспомнила о существовании вьюх в SQL У меня смутное ощущение что мне могут помочь оконные функции Как я понимаю, они позволяют нарезать селект на группы без собственно группировки, и потом эти группы можно отдельно друг от друга сортировать, и выбирать то самое максимальное значение что мне нужно Осталось только переделать тестовую базу под новую схему и потестировать.... стоп у меня кажется получился тот же самый group by... Поняв что я уперлась в тупик, я снова задалась вопросом «а что если» Почему я утром была такая бодрая и продуктивная, а щас смотрю на написанное для себя ТЗ как баран на новые ворота, и не могу додумать, что мне нужно поменять чтобы пробросить в API кусочек ещё одной сущности... Обидно, что как только я вроде бы подебила мозг, работать отказался ноутбук... Обидно, что как только я вроде бы подебила и ноутбук и мозг, пришёл РКН и сказал "сегодня без ваергарда" :blobcattableflip:  @oreolek это если айпишник белый. Белый там в лучшем случае IPv6. Который не факт что есть на том вайфае на котором я ща сижу @oreolek и через чьи сервера он из-за NAT вытаскивает порты? @mo звучит хрупко. Нужно будет постоянно следить за таймстампами при записи в БД. У меня недавно была возможно похожая ситуация. Я решил записать в таблицу истории статусов два статуса подряд. В одной транзакции. И я не учёл, что запрос на запись использует now в БД. И оно считается на момент коммита транзакции. А все запросы на чтение просто искали max по таймстампу. И в моём случае записей с максимальным таймстампом было две. И бралась первая по порядку, с неактуальным значением статуса. @mrcopperbeard да, но в моем случае таймштампы берутся из гита, и база знает только о тех коммитах которые засветились в CI |
Надо запомнить уже наконец больше никогда не заполнять тестовые данные руками
Чатжпт это делает намного быстрее и удобнее