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

    +153

    1. 01
    2. 02
    3. 03
    4. 04
    5. 05
    6. 06
    7. 07
    8. 08
    9. 09
    10. 10
    11. 11
    12. 12
    13. 13
    14. 14
    15. 15
    16. 16
    17. 17
    18. 18
    19. 19
    20. 20
    21. 21
    22. 22
    23. 23
    24. 24
    25. 25
    26. 26
    27. 27
    28. 28
    29. 29
    30. 30
    31. 31
    32. 32
    33. 33
    34. 34
    35. 35
    36. 36
    37. 37
    38. 38
    39. 39
    40. 40
    41. 41
    $statement = $pdo->prepare(
         "if not exists
          (select daily_serving_start, daily_serving_end,
                  weekly_service_off, one_time_service_off
          from menu_availability_rules
          where
            (daily_serving_start = :start0 or
             (daily_serving_start is null and :start1 is null)) and
            (daily_serving_end = :end0 or
             (daily_serving_end is null and :end1 is null)) and
            (weekly_service_off = :weekly0 or
             (weekly_service_off is null and :weekly1 is null)) and
            (one_time_service_off = :once0 or
             (one_time_service_off is null and :once1 is null)))
          begin
            insert into menu_availability_rules
             (daily_serving_start, daily_serving_end,
              weekly_service_off, one_time_service_off)
            values (:start2, :end2, :weekly2, :once2)
          end
    
          if not exists
          (select menu_id, daily_serving_start, daily_serving_end,
                  weekly_service_off, one_time_service_off
          from menu_availability
          where
           menu_id = :menu_id0 and
           (daily_serving_start = :start3 or
             (daily_serving_start is null and :start4 is null)) and
            (daily_serving_end = :end3 or
             (daily_serving_end is null and :end4 is null)) and
            (weekly_service_off = :weekly3 or
             (weekly_service_off is null and :weekly4 is null)) and
            (one_time_service_off = :once3 or
             (one_time_service_off is null and :once4 is null)))
          begin
            insert into menu_availability
             (menu_id, daily_serving_start, daily_serving_end,
              weekly_service_off, one_time_service_off)
            values (:menu_id1, :start5, :end5, :weekly5, :once5)
          end");

    Мое :( А что делать?

    Запостил: wvxvw, 10 Марта 2013

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

    • > А что делать?
      Ключи юзать. Даже если NULL-ы мешают - можно добавить специально колонку для чего-то вроде хеша по этим 4-5 параметрам, чтобы база могла уникальность проверить.
      Ответить
      • Смысл не в этом, базу сейчас менять уже никто не будет, смысл в :foo0, :foo1, :foo2 и т.д. Как бы от ПХП можно было всякого ожидать, но это по настоящему подло.
        Ответить
        • Вы не то говно исправить пытаетесь.
          Ответить
          • Ну да это не имеет значения в данной ситуации. Я просто выбирал запрос, где много параметров, для наглядности. То, что база плохо спроектирована - это отдельная история заслуживающая персонального освещения в средствах массовой информации, но тут речь не о ней.
            Ответить
            • Это MSSQL? Если мне не изменяет память, там можно было переменные объявить, чтобы сохранить в них параметры, и не передавать их по 4 раза.
              Ответить
              • Даже не знаю, что вам и сказать... что делает запрос - не имеет значения, какая это СУБД - не имеет значения, смысл в недоделанном PDO в ПХП, который не умеет подставлять одинаковые значения.

                ЗЫ. В переменную - не получится, это разные таблицы, если уж на то пошло. Просто в одной таблице ФК = юник из из другой таблице, ну и имена соответственно такие же, но это опять, же не имеет значения, этой таблицы уже несколько часов как не существует вообще - нашелся способ ее удалить и распихать остатки туда, где они должны были быть изначально. Печаль же осталась...
                Ответить
                • Ну вот... А говорите, что базу никто менять не будет. :)
                  Ответить
                  • Ну я подумал-подумал, и решился... хз, наверное, что-то сломал где-то, узнаю на днях, может быть :)
                    Ответить
    • Программист на ЛИСПе может писать на любом языке как на Л и в php составить запрос, отформатировав его как ЛИСП-код.
      Ответить
      • Если честно, то я умаялся искать редактор в котором можно было хотя бы посмотреть на "типичное" форматирование сиквела. Студия - вообще никак не форматирует, как хочешь, так и расставляешь табы. В Эмаксе есть что-то, но работает очень странно.
        Когда я смотрю документацию, или примеры, то там тоже, кто с какой ноги утром встал, тот так и написал. Поэтому, а что делать?
        Ответить
    • Стреляться.
      P.S. Почти всегда есть альтернатива переписать благодатнее в insert-into-select-from.
      Ответить
    • А что это такое вообще?
      Ответить
      • Запрос на лиспе.
        Ответить
      • По памяти, т.как таблиц этих больше нету:

        menu_availability_rules
         (daily_serving_start, daily_serving_end,
          weekly_service_off, one_time_service_off)
          <куча разных других констрейнов, типа ограничений на дни недели и т.п.>
          unique (daily_serving_start, daily_serving_end,
          weekly_service_off, one_time_service_off)
          и
        menu_availability
         (menu_id, daily_serving_start, daily_serving_end,
          weekly_service_off, one_time_service_off)
          foreign key menu_id references some_other_table(...)
          foreign key (daily_serving_start, daily_serving_end,
          weekly_service_off, one_time_service_off) references
          menu_availability_rules(...)

        Как-то так. Практический смысл этих двух таблиц: в одной хранятся "правила", когда ресторан не продает какой-то из пунктов меню, а вторая таблица - ассоциация правило-меню. Врезультате переделалось с добавлением колонки id в таблицу с правилами, и второй ФК теперь по ней.

        И написанием утилитных функций, которые сами создают поля типа $foo#, и запихивают сколько нужно аргументов :|
        Ответить
    • Интересно.
      В заголовке PHP, код на 95% состоит из sql, а выглядит как лисп.
      Повеселило.
      >А что делать?
      Использовать хранимые процедуры? Выносить запросы в отдельный файл? Не форматировать как S-выражения?
      Ответить
      • Хранимые процедуры было бы правильно, но я пока что на правах нового сотрудника... и когда я об этом заикнулся, дурачок со стажем пришел в ярость, затопал ногами, и сказал Ноде.ЖС и Монгодб. Он еще хочет составить план работ и все хорошо обдумать (уже два года, календарных, обдумывает). Вот я надеюсь, что он начнет когда-нибудь план составлять, а я тем временем базой займусь. Там на план еще много времени уйдет, принимая во внимание, что даже про концепцию ETL человек не слышал еще...
        Ответить
        • Поясни за хранимые прцедуры и чем тебе монгодб не угодил?
          Ответить
          • Мне он (пока) ничего не сделал. Просто его достоинства очень сильно муссируются в средствах массовой информации. Но у меня есть предчувствие, что технология напрямую работающая с ж. скриптом не может быть хорошей. Я за последний месяц столько насмотрелся на серверный ж. скрипт (ASP), что я просто никогда не поверю в то, что это можно сделать хорошо. Это какой-то язык с полностью атрофированой возможностью органицационного начала: в ПХП можно делать месиво из сиквела, ХТМЛ и ж. скрипта, но можно напрячься и написать классы, модули и т.п. Но я еще не видел ни одного модульного приложения на ж. скрипте.
            Ответить
            • А на нём фирефоксоосы пишут!
              Ответить
            • SICP как бы непрозрачно намекает, что для возможности бороться со сложностью ПО нужно совсем немного: наличие примитивов и удобная возможность строить абстрации.
              Поскольку JS довольно сильно похож на Scheme, возможность построения астракций с его помощью сложно подвергнуть сомнению.

              Другое дело, что любой гибкий и мощный инструмент в руках идиотов легко превращается в сами знаете что.
              Ответить
              • Ну, положим, есть такое дело что... в ж. скрипте кроме непосредственных языковых сложностей (отсутствия модулей и неовозможности их как-то эмулировать) существует укоренившаяся традиция не замечать эту проблему.
                Например, чуть ли ни единственная универсально используемая библиотека ж. квери является по сути и задумке божественным объектом (одним, чтобы не дай бог пользователи не запутались), и вереницей, по сути ставших глобальными, методов этого объекта.
                Приложениям на ж. скрипте не свойственны иерархии, вообще никакая структура. Это как правило большой список функций.
                Еще такой момент: когда в Яве используется import, или use в ПХП и им подобные - в еденице программы, программист достаточно четко представляет, что ему тут доступно. В ж. скрипте в любом месте программы доступно все, и соответственно, программа становится неуправляемым монстром из кучи отдельных участков кода, которые никак не связаны между собой. Повторное использование кода в такой ситуации стремтися к нулю. Скорость разработки падает не пропорционально размеру проекта, а, возможно даже там какая-нибудь квадартичная зависимость (т.е. разработать проект в два раза более сложный чем проект Х займет не в два раза больше времени, а, возможно, в четыре).
                Кроме того, чтобы разрешать строительство абстракций, язык должен так же больно наказывать за их игнорирование. В ж. скрипте наказание приходит очень поздно.
                Ответить
                • В Scheme (до последней версии стандарта) тоже нет модулей. И нет объектов, лишь не особо изящный способ их эмулировать. И циклов тоже нет.
                  Модули в JS прекрасно заменяются объектами. В Python, к примеру, модули тоже по сути - обычные объекты-синглтоны.

                  > Приложениям на ж. скрипте не свойственны иерархии
                  Flat is better than nested. Иерархии нужны не всегда. Да и объекты могут содержать объекты, поэтому иерархии всё-же возможны.

                  > разработать проект в два раза более сложный чем проект Х займет не в два раза больше времени, а, возможно, в четыре
                  Это не зависит от языка программирования. Это общее свойство всей разработки ПО.
                  Ответить
                • >разработать проект в два раза более сложный чем проект Х займет не в два раза больше времени, а, возможно, в четыре

                  Позвольте предложить такую критическую мысль: если проект занимает в 4 раза больше времени, то он в 4 раза сложнее, а не в 2, а начальная оценка была попросту неверной.

                  И, как уже заметил Роман, выбор ЯП тут ни при чем - просто сроки для больших проектов оцениваются неверно. Интересная книга по теме: "Факты и заблуждения профессионального программирования" Р. Гласс.
                  Ответить
                  • И сколько больших, да и вообще просто не учебных приложений написано на Схеме?
                    Модули не заменяются объектами... это, как заменить сахар стиральным порошком...
                    Иерархии, или вообще хоть какая-то структура нужна большим приложениям. Если бы это было не так, люди бы по-прежнему писали на ассемблере все, не создавая никаких структур над ним.

                    Как говорил Буш младший: read my lips, проетк в два раза сложнее написать в четыре раза сложнее, проект в три раза сложнее - в девять раз сложнее, проект в четыре раза сложнее - в шестнадцать раз сложнее. Это делает написание проектов среднего-большого размера на ж. скрипте бессмысленной тратой времени и человеческих ресурсов - дешевле написать транслятор с той же Явы, и нагенерить говно ж. скрипта, но временные и человеческие затраты будут линейными.
                    И временные / человеческие затраты взяты по отношению к другим технологиям, а не по отношению к какой-то произвольно выбранному "оптимальному" соотношению.
                    Я это говорю как человек, который имел возможность разрабатывать одно и то же приложение на Флеше и потом на ж. скрипте. Т.е. в такой ситуации обычно второй раз занимает минимум времени, т.как UOD уже известен, ETL в принципе уже большей частью сделан и т.д. И тем не менее, просто разработка ж. скрипта заняла неимоверно больше, чем оригинальная разработка на Флексе / Флеше.
                    Если интересно - речь идет о системе бух. учета / администрирования для British Airways.
                    Ответить
                    • Как минимум, scheme используется как язык расширения в gimp, ну и guile - "основной" язык расширений gnu.
                      eLisp не особо сильно отличается по сути от scheme, на самом деле (с моей точки зрения) он во многом хуже в плане модульности и структуризации приложений. Тем не менее, на нём написано очень внушительное приложение, которым я пользуюсь каждый день.

                      В каждом подобном споре я хочу донести одну и ту же мысь: язык сам по себе редко бывает виноват в косяках программиста. Я твёрдо уверен, что язык для отличного программиста должен существенно отличаться от языка для типичных раздолбаев. Я не скажу, что Java лучше, чем JavaScript. It depends. Даже для крупных приложений.
                      Я написал достаточно кода на Java, чтобы её недолюблибливать, но у неё есть ощутимые преимущества в виде сотен работающих библиотек и чрезвычайно развитой инфраструктуры.

                      К примеру, emacs бы только выиграл, если бы основным языком расширений был JavaScript, была бы только возможность сохранить макросы и аспекты (с аспектами вроде проблем нет, а вот макросы перенести сложнее).

                      И да, монструазный eclipse, написанной на "божественной" жабе, я люблю гораздо меньше.
                      Ответить
                      • Так и на еЛиспе нет больших программ... самое большое - CEDET, и это даже не дотягивает до 100000 строк. В еЛиспе есть все те же проблемы с модульностью, но в отличие то ж. скрипта, их по крайней мере признают. Например, если скомпилировать еЛисп со всеми ворнингами, то за не использование префикса пакета будет ворнинг. Кроме того, там можно по крайней мере добиться того, чтобы код был локальным для буффера, например. Опять же, макросы помогают в навигации по коду в том смысле, что убирают бесполезный шум вокруг и позволяют явно выразить намерения писавшего.
                        Если бы в еЛиспе сделали человеческие пакеты / неймспейсы и взялись немного за оптимизацию байткода, то получился бы вполне конкурентноспособный язык, сравнимый с Питоном или Руби. ж. скрипту до этих языков еще милю лесом, но он даже и не двигается в нужном направлении.
                        Ответить
                        • Емакс это и есть одна огромная программа на elisp.

                          А ведь есть ещё язык C, в котором нет ни пакетов, ни пространств имён, ни сборщика мусора, ни намёка на классы, ни встоенных высокоуровневых структур данных, ни удобной интерактивной среды. И типизация там оставляет желать лучшего.
                          И представляете, люди пишут на этом весьма работоспособные программы весьма внушительных размеров.

                          Всё зависит от программиста.
                          Ответить

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