1. SQL / Говнокод #20092

    −29

    1. 1
    2. 2
    3. 3
    4. 4
    5. 5
    6. 6
    7. 7
    8. 8
    SELECT AVG(sell) 
    FROM table_name
    WHERE id IN (
      SELECT id
      FROM table_name
      WHERE /* тут какое-то большое условие */
      ORDER BY day
    )

    Настоящий индус

    Запостил: jbot, 30 Мая 2016

    Комментарии (27) RSS

    • ORDER BY day CRIME BY night
      Ответить
    • Порядок ийдишников меняет их качественный состав? Это гениально!
      Ответить
      • зависит от субд
        оракловый оптимизатор и не такое говно преобразовывал к правильному плану выполнения
        если же это мускул, то программист соответствует своей как они говорят субд
        Ответить
        • по, моему, такое недостойно существовать в нашем пространстве-времени
          Ответить
          • что именно?
            порядок айдишников ни на что не повлияет нигде (хотя и есть шанс проффессионалы mysql сейчас набегут и скажут, что нет, не всё так однозначно)
            нормальная субд выкинет к ебеням и ордер, и подзапрос
            обратится к таблице ровно один раз и посчитает среднее
            Ответить
            • Я про код.

              Ясен пень, что в человеческих СУБД есть защита от макак, но блин, хоть одну книжку то нужно почитать по Sql прежде чем садиться за запросы
              Ответить
            • Не всё так однозначно!

              В MySQL порядок айдишников из подзапроса сохраняется. В MariaDB добавлен оптимизатор, и ордер бай из подзапроса ни на что не влияет. Очень весело, когда на проекте резко меняется СУБД: говнокод, заточенный под оригинальную MySQL, на MariaDB внезапно начинает выдавать неупорядоченные результаты (там даже в документации написано, что полагаться на сохранение порядка из подзапроса — UB).
              Ответить
            • > порядок айдишников ни на что не повлияет нигде

              из моего личного (ограниченого) опыта: народ такое пишет потому что вложеный запрос пишется/дебажится отдельно, и только потому копи-пастится в нужные места. (по крайней мере на оракле с PL/SQL его приходилось в лоб копипастить потому что по другому с Pro*C без граблей не работало.)
              Ответить
              • всё так
                только это допустимо у тебя в воркшите, который ты в течение дня используешь как консоль для одноразовых запросов
                а в продакшене это увидеть - как по весне в собачье говно наступить
                Ответить
                • > как по весне в собачье говно наступить

                  в теории - да. в практике...

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

                  простой пример который я помню, это параметризация выборки: выбор по дате/без даты и/или выбор по статусу/без статуса. на каждую комбинацию, своя оптимальная выборка, и только кусок where можно шарить. но единственный способ шарить c SQL - это глупая копипаста.
                  Ответить
                  • показать все, что скрытоа нельзя как-то предгенерять SQL?

                    Ну то-есть писать на хорошем DSL с DRY, а потом скриптом компилировать его в тонны унылого SQL?
                    Ответить
                    • я пытался пару раз чего делать, но и в релиз билд падало, и на ревью по рукам стучали: Oracle Pro*C/C++ очень очень глючная вещь, которая ломается на всем чем не попади. (например никто не мог понять почему некоторые вещи у разрабов работают, а на релизах вылетают уже с синтаксической ошибкой.)
                      Ответить
          • показать все, что скрытоМайсикл?
            Ответить
    • всем офисом оценили!
      Ответить

    Добавить комментарий