- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
SELECT AVG(sell)
FROM table_name
WHERE id IN (
SELECT id
FROM table_name
WHERE /* тут какое-то большое условие */
ORDER BY day
)-
SQL / Говнокод #20092
−29
Настоящий индус
Запостил:
jbot,
30 Мая 2016
Follow us!
оракловый оптимизатор и не такое говно преобразовывал к правильному плану выполнения
если же это мускул, то программист соответствует своей как они говорят субд
порядок айдишников ни на что не повлияет нигде (хотя и есть шанс проффессионалы mysql сейчас набегут и скажут, что нет, не всё так однозначно)
нормальная субд выкинет к ебеням и ордер, и подзапрос
обратится к таблице ровно один раз и посчитает среднее
Ясен пень, что в человеческих СУБД есть защита от макак, но блин, хоть одну книжку то нужно почитать по Sql прежде чем садиться за запросы
В MySQL порядок айдишников из подзапроса сохраняется. В MariaDB добавлен оптимизатор, и ордер бай из подзапроса ни на что не влияет. Очень весело, когда на проекте резко меняется СУБД: говнокод, заточенный под оригинальную MySQL, на MariaDB внезапно начинает выдавать неупорядоченные результаты (там даже в документации написано, что полагаться на сохранение порядка из подзапроса — UB).
есть случаи, когда порядок в подзапросе движок обязан сохранить и довести до запроса уровнем выше: (хотя подобную поебень можно переписать и в row_number() over...)
из моего личного (ограниченого) опыта: народ такое пишет потому что вложеный запрос пишется/дебажится отдельно, и только потому копи-пастится в нужные места. (по крайней мере на оракле с PL/SQL его приходилось в лоб копипастить потому что по другому с Pro*C без граблей не работало.)
только это допустимо у тебя в воркшите, который ты в течение дня используешь как консоль для одноразовых запросов
а в продакшене это увидеть - как по весне в собачье говно наступить
в теории - да. в практике...
большая проблема крупных проектов, это что бы выборки консистентное подмножество данных выбирали. и если у тебя нет другого способа это выборки между запросами разными шарить, то приходится извращатся. в общем случае view & SP помогают, но там то же какие-то грабли с ними в оракле были.
простой пример который я помню, это параметризация выборки: выбор по дате/без даты и/или выбор по статусу/без статуса. на каждую комбинацию, своя оптимальная выборка, и только кусок where можно шарить. но единственный способ шарить c SQL - это глупая копипаста.
Ну то-есть писать на хорошем DSL с DRY, а потом скриптом компилировать его в тонны унылого SQL?
На подобии Hibernate.
а у Вас что за ЯП?
наверное, вот - https://github.com/rbock/sqlpp11/wiki
я хз как работает
ORM на крестах, где вместо аннотаций и АОП можно только яйца кочергой себе почесать, ваще грозно звучит
Всё таки кресты берут наверное для перформанса, либо если нет API на более высокоуровневых ЯП.
Ни то ни другое не про ORM.