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

    +164.2

    1. 01
    2. 02
    3. 03
    4. 04
    5. 05
    6. 06
    7. 07
    8. 08
    9. 09
    10. 10
    11. 11
    while ($rst=mysql_fetch_array($rst_query))
    {
        $clist.="," . $rst["es_id"];
        $thislist="-1," . $rst["es_id"];
        while ($rst=mysql_fetch_array($rst_query))
        {
            $clist.="," . $rst["es_id"];
            $thislist.="," . $rst["es_id"];
        }
        $rst_query=mysql_query("Select * from esb2b_categories where es_pid in (" . $thislist . ")" );
    }

    разрыв мозга
    made by какой-то индус

    Запостил: primpil, 16 Ноября 2009

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

    • Посмеялся.
      Ответить
      • не смешно тут плакать нужно )))
        фтопку такие итерации
        Ответить
        • ага, я наплакался, пока разобраться пытался
          Ответить
        • в топку индусов, которые такое пишут. и заказчиков, которые у них сайты покупают.
          Ответить
    • К.О. - Это рекурсивный обход всех потомков, при том на каждой итерации выбирается ребенок у которого родитель равен "-1" (которого, по-видимому нет, иначе цикл некогда бы не закончился)

      Если в Мускуле есть конструкция connect by как в оракле, то надо использовать её.

      Пример мне тут понятен. Тут я даже не знаю минусовать или плюсовать. Предлагаю автору переписать пример и написать его в комментах.
      Ответить
      • ах-да, в примере, маленькая трабла:
        собирать айдишники родителей в одну строку не есть гуд, так как количество детишек (не важно от какого родителя) на каждом уровне может увеличиваться в геометрической прогрессии, в результате может быть наложен запрет на выполенение запроса (например, в оракле допустимо в конструкции in писать только тысячу элементов)
        Ответить
        • Вот в этом случае лучше переписать пример, чтоб длинная строка id-шников не собиралась)
          Ответить
          • а чо тут переписывать?
            конструкция использовалась для подсчета количества итемов в категории и всех ее дочках . выкинул сюда как есть. в принципе, нормальное решение, но там оно не по назначению используется. для 600к записей в таблице даже на мощном серваке при растущем числе посещений начинались серьезные проблемы. вкупе с остальным говнокодом приводило к тому, что сервак ложился даже от поисковых роботов.
            Ответить
            • Надо, видимо, где-то хранить уже подсчитанное количество итемов.
              Которое изменять при добавлении и удалении итема.

              Может если не выбирать сразу кучу записей, у которых айдишник родителей содержится среди кучи элементов, а выбирать детей от каждого родителя по отдельности, то будет руче. (то есть заменить строку thislist на массив, из которого на каждой итерации выбирать первый элемент, сдвигая остальные на его место (шифтить массив))

              Если подсчёт используется. Нафига тогда в строку $clist формировать?
              Ответить
              • --Если подсчёт используется. Нафига тогда в строку $clist формировать?--

                там $clist используется индусом в дальше в запросе, где и считается количество итемов.

                --Может если не выбирать сразу кучу записей...--

                да, это, возможно, лучший вариант, если подсчет ведется каждый раз при загрузке страницы. но все равно для нагруженного сайта гораздо лучше предложенный вами вот этот вариант:

                --Надо, видимо, где-то хранить уже подсчитанное количество итемов. Которое изменять при добавлении и удалении итема.--

                собсно, я перенес код подсчета итемов в отдельный скрипт и убрал там $clist. пока что этот скрипт кроном пару раз в сутки запускается и собранная инфа сохраняется в базу, и потом показываем на странице. не спрашивайте, почему так - там весь проект ужасный. это временное решение, скоро все будет переписываться с нуля.
                Ответить
            • Сервак ложился от поисковых роботов? Пхахахахах я плачу бляяяяяяяяяя
              Ответить

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