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

    −47

    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
    SELECT 'январь' mes, a.datogt, gr.date_ogt datogt_, a.id_grafik,
               a.date_ogt dat_zam, 0 pr_zam, TO_CHAR(gr.date_ogt, 'DD') dat_zam_,
               0 pr_zam_, a.date_inp dat_nach, 0 pr_nach,
               TO_CHAR(gr.date_inp, 'DD') dat_nach_, 0 pr_nach_
          FROM (SELECT id_grafik, TO_CHAR(date_inp, 'DD') date_inp,
                        TO_CHAR(date_ogt, 'DD') date_ogt, date_ogt datogt, god,
                        TO_CHAR(date_ogt, 'MM') mon
                   FROM protokol p
                  WHERE god = p_god
                    AND TO_NUMBER(TO_CHAR(date_inp, 'MM')) = 01
                    AND pr_protokol = 1
                    AND flag_a = 1) a
         INNER JOIN protokol gr
            ON gr.god = a.god
           AND TO_CHAR(gr.date_ogt, 'mm') = a.mon
           AND gr.pr_protokol = 2
           AND flag_a = 1

    И так 12 раз от января до декабря

    Запостил: raupe, 20 Апреля 2016

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

    • В смысле 12 юнионов
      Ответить
    • id_grafik... dat_nach... protokol... Пиздец какой. Лучше бы сразу по-русски поля назвали, чем таким транслитным убожеством.
      Ответить
      • но наименования полей это не самое страшное
        Самое страшное это юнионы чтобы вытянуть 12 месяцев
        SELECT 'январь' mes, ...
        union all
        SELECT 'февраль' mes,...
        ...
        union all
        SELECT 'декабрь' mes, ...
        такое чувство что способы извлечения наименования месяца из даты автору неизвестны
        Ответить
    • так всегда бывает, когда репорты делают не на OLAP кубах а на говноколенке
      Ответить
      • > OLAP кубах

        я как-то участвовал в прикручивании бэк-энда для SAP BusinessObjects к продукту.

        единственно чем тебе OLAP'ы "помогают", это то что они от тебя вот такое говно скрывают.
        Ответить
        • OLAPы помогают тем, что предагригируют все данные, и позволюят быстро и мышкой создавать отчеты, которые в обычном случае пишут руками программисты
          Ответить
          • отчеты мышкой это маркетинговая туфта
            ни разу не видел, чтобы у кого-то это реально заработало и не требовало программистов
            Ответить
            • ditto. у меня тогда тоже на это забили достаточно быстро. и стоило, и тормозило. и само собой разумеется нужен разраб что бы запросы писать/поддерживать с помощью которых статистика для чартов собирается.
              Ответить
              • >>и тормозило
                наверное потому что руки кривые, нет?
                Ответить
                • да нет, просто данных было много. и база была соптимизирована на ран-тайм производительность и для статистики просто не хватало индексов. и добавлять индексы только для статистики решили после того как кастомеры это будут покупать. но кастомеры (цену лицензии SAP BO не скажу) как то не сильно жаждали бабло отваливать только для красивых пай чартов. SAP BO результаты запросов кэшировало, и в общем случае это не было проблемой (но если хочешь актуальные данные, иди пей кофе). основные грабли были что там было два интерфейса: тупой для тупых кастомеров которые хотят чарты, и понавороченей для разрабов. SAP просто не предусматривал что навороченый интерфейс будет даватся кастомерам, и они не могли статистики под свой бизнес затачивать. а кастомеры у нас были не тупые. вообщем пару раз продали, но никто не пользовался.
                  Ответить
              • >>разраб что бы запросы писать/поддерживать с помощью которых статистика для чартов >>собирается.

                да нет, нет, нет!!
                Почитайте же что такое OLAP куб! Какие там надо "запросы писать"?

                https://www.youtube.com/watch?v=Il1MhgFQGUw
                Ответить
                • так а откуда у тебя кубы эти берутся?

                  или: как маркетолог из базы 1+ГБ данных/300+ таблиц себе этот куб соберет?

                  или ты "анализируешь" базу с траффиком в пару сотен/пару тысяч новых строк в месяц?
                  Ответить
                  • >> так а откуда у тебя кубы эти берутся?

                    оралук поддерживает "sql мышкой", так что быть программистом для создания сраных гиперкубов вовсе не нужно Это блядь необходимо, потому что в оралуке все через жопу! Интуитивный интерфейс настолько интуитивен, что боишься как бы базу не распидорасило вместе с компом!
                    Ответить
                  • > 1+ГБ данных
                    ээ, не, для такой херни олап не нужен
                    Ответить
                    • знаю что не типично. но в моем случае именно для этого и хотели: и базы всего автоматом вытягивать дневные/недельные/месячные/квартальные/годичные статистики и т.д.

                      так даже и "sql мышкой" работает (kegdan'овы флеймы про оракакал игнорируя) так "хорошо" как мы уже знаем больше 20 лет - на горьких уроках M$Access и его других предшественников.

                      мне это немного напоминает ситуацию с "mediation devices" лабудами. началось так же: даже секретарша может! мышкой диаграмку из пяти-десяти блоков набросал! блоки соединил! нажал run! воркфлоу побежал! пара минут и данные готовы! ... десять лет спустя, диаграмы выросли до сотен блоков, с вложеными под-диаграмами, с нетривиальными семантическими зависимостями между блоками и под-диаграмами, которые даже ветеранам и аксакалам недели нужны что бы разгрести что бы найти почему не работает. потому что в конце получился специализированный графический язык программирования, и как не крутись для него тебе нужен программист.

                      к чему веду. да, если у тебя данных и таблиц столько много что даже и стереотипичная секретарша может, то "sql мышкой" будет работать. но если у тебя какая даже полусерьёзная DDL, то там уже нужен некто кто эту дата модел понимает.
                      Ответить
                • Просто сначала нужно найти домохозяйку, чтобы она на сиквеле создала таблицы с тригерами, представлениями и т.д. А уже потом отдавать это все макретологу мышкой юлозить.
                  Ответить
            • Если отчёт мышкой - это настройка в гриде колонок, сортировки, группировки, фильтрации и нажатию на кнопу эксель/печать, то вполне реально )
              А так согласен.
              Ответить
              • ну понятно, понабежало ламеров, которые знать не знают что такое OLAP кубы и начинают тут рассказывать про "сортировку"
                Ответить
                • Ты свой олап-куб можешь в жопу себе засунуть. Не бывает нормальных отчётов без программеров, правильно defecate-plusplus сказал. В самом тривиальном отчёте найдётся проблема, которую нельзя решить с помощью интерфейса.
                  Ответить
                • Ещё один мудак, который изобрёл серебрянную пулю.
                  Ответить
                  • вы чего так окрысились? вам guesto бисер мечет, а у вас у всех обострение
                    зачем отрицать олап только за то, что с ним не работали?

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

                    и то этим отчеты (джаспер) и тупо выгрузки на порядок ускорил, теперь отчет на 50 колонок для квартальной премии тысячи сотрудников не полчаса грузится, а в пределах минуты

                    я вообще говорил о том, что к проектированию хранилища мышкой не подступишься, и кроме сумм/каунтов и срезов по измерениям часто кучу других задач перед отчетами ставят

                    guesto, за интеграцию экселя спасибо
                    оно работает с чем-то ещё, кроме ms sql server?
                    Ответить
                    • Никто не отрицает олап и все его возможности. Просто область применения олап кубов - это оптимизация времени расчёта больших данных, ессно, с программерами (бородатыми), блэкджеком и шлюхами.
                      Как, блядь, можно называть это "быстро и мышкой создавать отчеты", если это уже по определению без бородатых программеров не делается?
                      Ответить
                    • Когда-то очень давно я работал в большом и дружном коллективе разрабатывающим вот этот продукт: https://www.sapstore.com/solutions/99017/SAP-SQL-Anywhere-%28v17%29 . Или, скорее, его предшественника. Я, правда, только поверхностно знаком с тем, что он делает, т.как работал над фронтендом, где эти самые кубы нужно было представлять как-то.

                      Честно, мне тяжело представить полезность вообще всей этой затеи. С точки зрения статистики - ОЛАП, это недостаточно. С точки зрения пользователя типа бухгалтера или менеджера - слишком сложно. Пользователи типа менеджеров просто хотят запомнить минимальное необходимое количество операций нужных для того, чтобы получить отчет, и не хотят вдаваться в подробности того, как данные организованы, и какие другие сведения из них можно получить.
                      Ответить
            • ну вот у нас это прекрасно работало

              Программист собирает куб один раз, а потом маркетолог крутит его, как хочет

              Вы знаете как pivot tables в excel работают?
              Ответить
              • >Программист собирает куб один раз
                https://www.youtube.com/watch?v=vQ4dnBrtrWc
                https://www.youtube.com/watch?v=f8Kj44Pp8jM
                Ответить
                • Очень похоже на мое первое знакомство с оралуком
                  Ответить

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