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

    −119

    1. 1
    select count(*) from jxlspp_prices  where 0!=0  or catid = 2	}

    А вот так его!

    Запостил: virtual_cia, 07 Октября 2012

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

    • where 0!=0


      Где.. в параллельной вселенной конечно же!
      Ответить
      • хоть и вернет false, зато слышал, что
        where NULL!=NULL вернуло бы true, но уже в нашей вселенной.
        Ответить
        • может NaN != NaN?
          Ответить
          • http://ideone.com/CWW0x
            http://ideone.com/vkKvb
            Впрочем согласен.
            Ответить
            • То есть, a = NULL всегда false?
              Ответить
              • именно
                поэтому is NULL
                Ответить
              • a = NULL всегда NULL. Потому что это не вопрос а приказ ;)

                P.S. Ой, это SQL а не С++. Тогда любая операция с NULL (кроме is) всегда возвращает NULL, который в условных операторах засчитывается как false.
                Ответить
        • Прикол в том что NULL=NULL даёт false, NULL!=NULL тоже дает false
          Ответить
    • Похоже на самоклейку из поста выше, для генерируемой строки самое то. Лично сам предпочитаю пользоваться 1=1 для безусловного true, 1=2 для false.
      Ответить
      • WHERE 123*507+555 > 321*196
        Ответить
        • WHERE sin(100500) <= 1.0
          Ответить
          • Имелось в виду long.MaxValue :?
            ( http://govnokod.ru/10055 )
            Ответить
            • http://govnokod.ru/6107
              Да, обстановка на ГК в те времена была намного душевнее...
              Ответить
        • а вот такую фигню наблюдал в выхлопе какого-то пхп-обфускатора. Но там именно пых был.
          Ответить
        • Ой да ладно. Вполне переносимое сравнение, которое вполне очевидно.
          Ответить
        • WHERE 123.2*11.1 == 123.2*11.1
          На некоторых платформах вернет false, а на некоторых true
          Ответить
          • Кстати, bormand выше написал гораздо лучше.
            >WHERE sin(100500) <= 1.0
            Ответить
            • лол это тоже платформозависимо
              Ответить
            • WHERE military_time = 1 AND sin(100500) <= 42.0 OR sin(100500) <= 1.0
              Иначе сломается при нападении противника
              Ответить
          • DELETE FROM users WHERE 0.1 + 0.2 = 0.3

            (и молимся, чтобы SQL считал это во флоатах, а не в децималах)
            Ответить
            • Во, правильный подход к платформазависимому рандому
              Ответить
            • А ты уверен, что во флоатах не сойдётся?
              Ответить
              • Если они по стандарту IEEE 754 - уверен.
                Ответить
                • С чего ты взял, что погрешности не окажутся одинаковыми?
                  http://ideone.com/w6PRN
                  Ответить
                  • Интересно. У флоата совпадают, у дабла - нет:
                    http://ideone.com/BAPoe
                    Ответить
                    • КО как бы намекает, что у даубла больше точность, поэтому в то время, когда флоат ещё не расходится из-за большей дискретности (больше растояние между дискретами), то даубл уже поехал.
                      Ответить
                      • Да нет, просто везение, порублены на разных разрядах. Во флоате удачно отрубилось, в дабле не очень.

                        Как 0.1, так и 0.2 и 0.3 это бесконечные двоичные дроби:
                        0.1 = 0.00(0011) = 0.0000110011...
                        0.2 = 0.00(0110) = 0.0001100110...
                        0.3 = 0.00(1001) = 0.0010011001...

                        Если складывать так - все ок:
                        0.0000110 + 0.0001100 = 0.0010010

                        Если же на один разряд больше - то фейл:
                        0.00001100 + 0.00011001 = 0.00100101

                        Если еще на один разряд больше - опять все ок:
                        0.000011001 + 0.000110011 = 0.001001100
                        Ответить
                        • Тык я о том же.
                          Ответить
                          • > Тык я о том же.
                            > в то время, когда флоат ещё не расходится из-за большей дискретности (больше растояние между дискретами), то даубл уже поехал.

                            Не-не-не девид блейн. Дискретность и то что дабл длиннее флоата тут к делу совершенно не относится. Тут дело в точном количестве разрядов - если бы дабл был бы на разряд короче или длиннее - получился бы корректный ответ. А если флоат был бы на 1-2 разряда короче, лень считать на сколько именно, то он бы тоже глючил. Вот так.
                            Ответить
      • *ковыряется в носу*
        А мне не бывает лениво сделать в склейке условий '<условие> AND ' и после всей цепочки сделать сабстринг или лефт без 5-ти символов последних.
        Зато на выхлопе запрос - красота.
        Но против 1=1 ничего не имею, техника неплохая.
        Ответить
        • В том же пыхе:
          $conditions = array("a = b", "c like 'd%'");
          $where_clause = implode(" AND ", $conditions);
          Ответить
        • Не всегда можно обрезать условия, совсем не всегда. Да и обрезать заранее известное значение тоже не сильно красиво.
          Нужен какой-то форматтер, который будет это учитывать. А не изобретать велосипед.
          Ответить
    • Блин, вы прикалываетелсь?
      Почему просто не написать "SELECT * FROM `xxx` WHERE 1; " или "SELECT * FROM `zzz` WHERE 0; " или "SELECT * FROM `xxx` WHERE true; "
      или просто "SELECT * FROM `xxx`"?
      В данном случае "where 0!=0 or catid = 2" равносильно "SELECT * FROM `xxx` where catid = 2".

      На кой здесь вычисления и сравнения?
      Ответить

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