1. PHP / Говнокод #12346

    +66

    1. 1
    2. 2
    3. 3
    4. 4
    5. 5
    6. 6
    7. 7
    8. 8
    @$maxday=mysql_result(mysql_query("
   select max(`day`) from `hours` 
      where `login` in (
         select `login` from people 
         where `type`='1' and `show`='yes') 
      and `begin`='10:00'
      and `end`='18:00'
      and `login`!='roma'"),0);

    Рома, мы от тебя устали.

    Запостил: madfriend, 24 Декабря 2012

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

    • ava Мистер Хэнки 24.12.2012 22:17 # +3

      Рома. извини. но мне надо бежать.
      Дела, дела, дела.
      Рома извини, но у меня самолёт.
      Пока, пока, пока.
      Ответить

      • ava Govnocoder#0xFF 24.12.2012 22:50 # +2

        Сочиняю роман,
        Рома рома роман, роман,
        Цеель всеей моей жиизниии.
        Ответить

    • ava tirinox 24.12.2012 23:07 # 0

      И че это значит?
      Ответить

      • ava Vindicar 25.12.2012 10:58 # +1

        Ну говна тут порядком, одно только IN и вложенный запрос вместо нормального join'а чего стоит...
        Но речь о последней строке:
        and `login`!='roma'"


        Этакий захардкоженный банлист %)
        Ответить

        • ava DBdev 25.12.2012 12:28 # +5

          > одно только IN и вложенный запрос вместо нормального join'а чего стоит...
          А ничего оно и не стоит, ибо оптимизатор запросов умнее всех и ядру БД отправятся одинаковые планы, что с джоином, что с ином. Вот так-то...

          Ну Рома, это да... лоханулись разработчики БД. Можно же добавить флаг в таблицу - IsRoma.
          Ответить

          • ava bormand 25.12.2012 15:01 # +3

            > Можно же добавить флаг в таблицу - IsRoma.

            Или, если база позволит, запилить вьюху hours_without_roma, в которой записи с ромой вырезаются.
            Ответить

            • ava Steve_Brown 25.12.2012 15:04 # +10

              Можно же сделать свой форк MySQL_no_roma, который сразу вырезает все записи с ромами.
              Ответить

          • ava eth0 25.12.2012 17:10 # +4

            Да вот хрен знает. Эти ваши оптимизаторы иногда бывают упоротее всех упоротых и некисло промахиваются.
            Точных причин и кода я уже не помню, но вот кулстори. Однажды я перешёл с Нормальной БД™ на mysql. По старой привычке, приобретённой на НБД™, я написал запрос с подзапросом в секции where, где выбирал максимальное (кажется) значение по неким данным из основного запроса. Искренне полагая, что внутрь подзапроса перейдёт немножечко данных из основного запроса. Собсна, в НБД™ я так и делал время от времени. В mysql, как оказалось, всё немного иначе. Оно сначала пытается выбрать данные подзапроса (миллионы), потом хитро умножить на данные основного запроса, найти максимальное и только потом пересечь. Этот запрос работал пару дней, пока в таблице подзапроса не накопилось достаточно данных, отчего сервер mysql сошёл с ума, начал есть травуповесил систему примерно на 101% загрузки. Благодаря инженерному подходу и смекалке, я переписал запрос как надо, попутно оптимизировав. Сам дурак? Понадеялся по привычке зря? Но осадочек-то остался.
            А морали сегодня не будет, нет.
            Ответить

    • ava roman-kashitsyn 24.12.2012 23:26 # 0

      Да ладно, потерпите ещё немного.

      > from people where `type`='1'
      у хирургов все люди делятся на один тип?
      Ответить

    • ava m_hamlet 25.12.2012 17:12 # −1

      А может roma не забанен? Может это какой-то тестовой юзер, или ещё что там...
      Ответить

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