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

    +152

    1. 1
    2. 2
    3. 3
    $result = mysql_query ("SELECT f.name, f.category, c.name AS cat_name, f.size, f.datetime, f.filename " .  
                           "FROM ${DB_PREFIX}_files AS f, ${DB_PREFIX}_categories AS c " .
                           "WHERE f.id=$id AND f.category = c.id");

    На момент написания совершенно не подозревал о существовании JOIN'а.

    Запостил: byss, 27 Декабря 2010

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

    • говносинтаксис Mysql неявно поощрает незнание джойнов)

      кстатиm о PDO Вы видимо так же не знали. ))
      Ответить
    • Для новичка это вполне адекватный запрос, только непонятно зачем надо было склеивать строки в запросе...?
      Минусую, ИМХО, не ГК
      Ответить
    • Разве mysql сервер не раскрывает JOIN в такой вот запрос?
      Ответить
      • скорее наоборот: такой запрос раскрывается в иннер джойн
        но Вы правы: это синонимы
        Ответить
    • Да какой это говнокод, вы что? Вот когда от незнания джойнов городятся запросы в цикле... >_<
      Ответить
    • кстати код говно в независимости от качества скул запроса
      Ответить
      • это потому что без PDO ??
        Ответить
        • ага
          а еще потому что с глобальной переменной
          Ответить
          • Вот не въезжаю... Зачем это PDO нужнО?
            Чем оно лучше собственной микро-архитектуры порождения из двух-трёх классов?
            Ответить
            • тем же чем и проверенные протестированные либы лучше своих великов.
              Ответить
              • имхо, как-то они имеют стремление из легковесных эволюционировать в тяжеловесные
                Ответить
                • ага)
                  и вместо стандартной либы у нас будет 42 наколенных и кривых
                  и таких же жирных

                  удивительно, что такие очевидные всему остальному миру вещи -- Не очевидны некоторым пхпистам
                  Ответить
                  • ну в 95% случаев, конечно, лучше взять стандартную либу.
                    Лисапеды одобряю в 2 случаях:
                    1. стандартная либа слишком универсальна и тяжела для мелкого проекта
                    2. стандартная либа спроектирована на коленке(криво) и не рефакторится из соображений обратной совместимости
                    Ответить
                  • Стандартные библиотеки хороши, когда они решают задачу, которая не может быть эффективно решена быстро. Если задача очень проста и конкретна, то смысл чужой библиотеки теряется. Дольше времени и сил уйдёт на понимание чужих ошибок, чем сразу создать маленький аналог -- простой и прозрачный.

                    И да. 42 велосипеда лучше чем один стандартный и совершенный. Пролиферация, однако.
                    Стандартизация нужна лишь для общения в коммуникативной группе. Если группа разработчиков А не общается с группой B, то им и не нужна общая стандартизация.
                    Ответить
                    • Не хочу вас растраивать, но вы, кагбэ, сравниваете 42 велосипеда использующие одну стандартную библиотеку с другой стандартной библиотекой, что весьма неправильно. // Ваш кэп
                      Та библиотека что используется в сабже, безумно древняя, и давно не поддерживается, плюс ко всему не поддерживает новый алгоритм аутентификации, транзакции и прочую утварь.
                      Ответить
                      • 42 велосипеда - новый мем?
                        Ответить
                      • Согласен.
                        Коннектор устарел. Признаю, что PDO действительно действенно. Скомпилировано расширение полностью в обход стандартного коннектора.
                        Конечно, в таком случае, уже велосипеды лишние.
                        Ответить
                    • 1) Все с точностью до наоборот. Свои решения нужны когда неподходит ни одно готовое решение. Вы знаете функцию nl2bnr? Вы ведь наверняка напишете такую же в течение 10 секунд. Но Вы не будете этого делать, потому что она уже есть.

                      2) Если Ваш программист существует в замкнутом мире и обладает неограниченым временем, то конечно лучше писать все с ноля.
                      Однако если Вы хотите что бы кроме автора кода еще кто-то мог с ним работать (как это принято в XP например) или что бы код можно было передать другому программисту или что бы в комманду можно было ввести разработчиков, словом сделать все то, что обычно делают в проектах сложнее гостевой книги из 50ти строк -- то стандартизация Вам только наруку. Нужно объяснять почему?
                      Ответить
                      • Когда есть библиотека, которая вас полностью устраивает -- вы её используете. Но если она вас не устраивает, например, излишней общностью и сложностью, делая задачу непрозрачной, то вы пишите свою, либо оборачиваете чужую так, чтобы она выглядела удобным для вас образом. Мне приходилось делать и первое, и второе.
                        Конечно, я не буду переписывать nl2br, потому что она в точности реализует то, что мне нужно, да ещё и такой простой и мелкой единицей. А вот "умный" указатель, скорее всего, напишу свой, под свои цели.

                        Я полагаю, что стандартизации следует избегать по максимуму. И только в случаях исключительной необходимости, когда действительно возникает серьёзная потребность объединить коммуникации, стандартизация нужна.

                        На мой взгляд, COM -- вот истинный пример ужаса стандартизации... Решили сделать общение между компонентами, да поуниверсальнее, да вот чтобы прям всё "стандартным" образом. Получили ужасный неповоротливый дом. Работать с ним непросто, хотя и абстрактная идея очень хорошая и ясная.

                        На самом деле всегда существует целый спектр библиотек, которые выполняют одни и те же задачи, но как-то по-разному. Хотя можно было стандартизировать одну. Но зато есть выбор. Выбор -- это хорошо.
                        Ответить
                      • >> Вы знаете функцию nl2bnr?
                        Неа =)
                        Ответить
            • 1) отсутствием SQL инъекций
              2) простотой перехода на другую БД (при условии выноса запросов в отдельные файлы / хранимые процедуры)
              3) единообразностью подхода, позволяющей программисту изучить "работу с БД в PHP". Как тут писал недавно товарищ: лучше понять концепцию, чем заучивать тонну несвязанных фактов.
              Ответить
              • >отсутствием SQL инъекций
                Как же это связано с PDO? Конкретно.
                Я так же легко смогу напрямую данные откуда-неизвестно пихануть в метод из PDO и просрать базу.

                >простотой перехода на другую БД (при условии выноса запросов в отдельные файлы
                Так простенькая таксономия собственного производства это решает быстрее и яснее для данной команды разработчиков.

                >единообразностью подхода, позволяющей программисту изучить "работу с БД в PHP"
                Странно звучит...
                То есть, базы данных это какие-то "особые" программы, которые "должны" как-то "реализовываться" в "языке"?
                Может это проблемы миграции из C, где у меня был голый MySQL API. Но мне яснее понимать, что база данных -- это ровно такая же программа, как и другие, которой можно делегировать какой-то функционал (хранения данных, например) через API, а не мыслить что-то "особенное".

                Я вот понимаю JDBC -- там адаптеры предоставляются производителями баз данных, там ISO. Классы специфики отделены.
                А в PDO ничего этого нет...
                Ответить
                • 1) PDO поддерживает установку параметров, что делает инъкцию технически невозможной. Почитайте про PDO и про его аналоги в других платформах (ado.net, jdbc)
                  2) зачем нужно собственное производство? и чем оно быстрее? Свое производство -- лишняя трата времени на создание того, что уже есть.

                  3) какое отношение ISO имеет к JDBC?
                  И разницы между PDO и JDBC нет никакой кроме того, что в мире Java понимают, зачем нужно JDBC, а в мире PHP любят велосипеды с квадратными колесами.
                  Ответить
                  • >что делает инъкцию технически невозможной
                    Совершенно не ясно.
                    Оттого, что вы связали переменную с частью запроса, вы не освободились от необходимости ставить "плотины" на эту переменную. Иначе вы точно также пропустите бяку.

                    >какое отношение ISO имеет к JDBC
                    Да, это я перегрелся. Привычка C++, чуть что -- кричать ISO.
                    Имеется в виду, что для JDBC существует стандарт того, как нужно осуществить адаптер. Это не ISO, конечно, а набор тестов, как я вычитал. Это позволяет производителям, например, баз данных заранее знать, что нужно сделать, чтобы подпихнуть адаптер под JDBC и быть уверенными, что разработчик сможет работать с их базой данных из под JDBC.
                    И много есть инструментов для того, чтобы дать возможность уже разработчиками адаптеров написать этот сопрягающий элемент, причём даже полностью на Java. А за счёт этого промежуточного уровня есть возможность даже корректировать запрос, то есть писать его в общем виде в смысле Java, а на выходе получить диалективное выражение.

                    Конечно, я про PDO знаю ещё меньше, чем про JDBC, надеюсь, что мне с PDO и работать-то не придётся. Но выглядит это PDO из описания, словно такой мощный синтаксический сахар.
                    Ответить
                    • ну почитайте же Вы про PDO, и узнаете что переменные там экранируются автоматически (как и в jdbc как и в ado.net) и если Вы делаете where name = :foo, а потом устанавливаете параметр foo в значение "O'Kelly", то кавычка экранируется.

                      Вообще есть такой бест практис: немного почитать про то, о чем собираетесь спорить)

                      Наличие более внятного контракта для JDBC это лишь отражение того факта, что в Java вообще принято мыслить интерфейсами и концепциями, а не конкретными функциями как в php, и появление поддержки новой БД в Java, .NET или perl это всего лишь появление нового драйвера (имплементации), с уже знакомыми нам интерфейсами. В случае же классического пхп подхода -- это появление пачки новых функций в глобальной области видимости с какими-то префиксами и разнообразным синтаксисом (вплоть до разного порядка параметров)
                      Ответить
    • - И попроси её не говорить моим родителям. А то выпускной я буду отмечать в реанимации.
      Ответить

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