mysql_real_escape_string / Говнокод #9328 Ссылка на оригинал

0

  1. 1
  2. 2
  3. 3
  4. 4
Select *
...
FROM (SELECT * FROM rtv_head) h
...

Наверно с запасом на будущее - "чтобы просто вписать лишь необходимые поля"

Запостил: Denisnetkin Denisnetkin, (Updated )

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

  • Выдрано из контекста, сомнительная говнистость.
    Ответить
      • Про говнистость подзапроса со * с Вами спорить никто не собирается.
        Вопрос, как Вы это подали.
        Вот выложили бы весь запрос, или хотя бы его верхнюю часть до момента с подзапросом.
        Написали бы в комментарии, что-то типа "Автор явно не понимает как использовать подзапросы"
        А это, что у Вас там? "чтобы просто вписать лишь необходимые поля" - это цитата ответа автора кода на Ваш вопрос к нему "Зачем ты так накодил?"? Это нам догадываться надо самим, что Вы нам донести хотите в виде говнистости?
        Ответить
        • Да какой бы ни был запрос в оригинале - зачем такой подзапрос? от него же никакого толку вообще.
          Мой коммент к куску - это стеб над автором.
          Ответить
          • В конструкции WHEN .... EXISTS ( тут может идти подзапрос со *)
            т.к. не имеет значения вообще какие поля выбираются
            Больше сходу ничего вспомнить не могу, но для себя НЕ исключаю возможности увидеть где-то подзапрос со *.
            ЗЫЖ Да, я вижу что в Вашем посте стоит FROM(подзапрос), что автоматически исключает приведенный мой пример. Но на Ваш вопрос "Какой смысл писать подзапрос чтобы выбрать ВСЮ таблицу?" отвечает.
            Ответить
  • Запрос говно, поскольку подзапросы редко когда имеют оправдание. Тем не менее, говно унылое.
    Ответить
    • > подзапросы редко когда имеют оправдание
      мне это утверждение кажется спорным...
      Ответить
    • Главное - это задать себе вопрос, когда рука тянется написать эдакое с подзапросом: а можно ли вот это все написать так же, но без перламутровых пугов^W^Wподзапросов?
      Ответить
    • Во-первых, это не подзапрос, а вложенная таблица (derived table).
      Вложенные таблицы всегда быстрее временных и во многих случаях они упрощают жизнь.
      Ответить
      • А вот чисто так, из любопытства, можете объяснить в чем различия между подзапросом и вложенной таблицей? Только в том, что вложенная таблица - это SELECT * FROM Table, а подзапрос - это еще чтоб со свистелками и перделками (ограничение выборки, перечисление полей, группировка и т.п.)?
        Только ссылку на реализацию какой-то конкретной СУБД давать не надо, а то знаете ли, в одной СУБД по одному назвали, в другой по другому.
        Ответить
        • > на реализацию какой-то конкретной СУБД давать не надо
          Кратко: различие в том что вложенная таблица практически всегда превратится в joinы. Это происходит из-за ограничения: в ней нельзя использовать поля из основного запроса, в подзапросе можно. И такой подзапрос называется коррелированным.
          Ответить
        • Нихера кратко не получилось.
          Также в некоторых СУБД можно делать top на вложенных таблицах и сортировать их, и в этом случае они не будут существенно отличаться по скорости от подзапросов.
          Но главное отличие в том что вложенные таблицы можно джойнить на другие по нескольким полям, вот так:
          select * from tableA, (derived table) dt,tableB
          where
          tableA.id=dt.id and tableB.name=dt.name

          А в подзапросе можно только одно поле в in использовать. И всё.
          Ответить
          • Очень тонкое и сомнительное для заострения внимания разделение. Если человек называет все подзапросами - нормально. Главное, чтобы он понимал механику их действия и область применения. Будь я заядлым ораклистом кричал бы, что это нифига не derived tables, а inline views. А будь я постгришником, то говорил бы что это subselect. Но это все одно и тоже.
            ЗЫЖ В стандарте ANSI SQL 2003 http://savage.net.au/SQL/sql-2003-2.bnf.html
            <derived table> ::= <table subquery>
            Ответить
            • Нет. Отличие существенное. Оно больше похоже на функционал нижеупомянутого witha.

              Просто я привык, selectы вложенные в условия называть подзапросами, а selectы в поле from вложенными таблицами, потому что там перечисляют именно таблицы.

              >нифига не derived tables, а inline views
              Кстати звучит.
              Ответить
      • Для этого в человеческих вариациях SQL вменяемых СУБД есть with'ы.
        Ответить
          • Удобство. Результать with'а может быть сjoin'ен с чем угодно любое количество раз, хоть сам с собой, может быть использован в любом нижележащем with'е.
            С подзапросами в виде таблиц не сталкивался, ибо ваистенуне нужно оно никогда мне, но, вероятно, реиспользовать её явно не получится, не?
            Ответить
            • Я понял.

              >может быть использован в любом нижележащем with'е.
              Да, так однозначно не получится.
              Но ведь with есть далеко не везде, а табличные подзапросы - стандартны.
              Ответить
              • Все таки "подзапрос", но только табличный, да? 🙂
                Мне определение того, что подзапрос - это более широкое понятие, чем вложенная таблица и вложенная таблица - это частный случай подзапроса, больше нравится, нежели строгое деление на подзапрос и вложенная таблица.
                Ответить
                • Пожалуй соглашусь.

                  >Все таки "подзапрос", но только табличный, да? 🙂
                  Ну раз даже в стандарте написали "table subquery". 🙂
                  Ответить
            • Может я что не так сделал, но сколько раз UNION полученного WITH'a столько раз запрос и выполнялся.
              Так что если и выглядит лаконично, то нифига не эффективно.
              Ответить
              • База, запрос, вывод плана профилировщика/анализатора.
                Ответить
                • база на оракле
                  WITH buh AS
                  (
                      select (location||'
                  '||loc_name_p) as loc, location as loc_id, location, item_type_p, move_type, row_name, row_value 
                      from ...
                  )
                      SELECT loc, loc_id, item_type_p, case move_type when -1 then 3 else move_type end as move_type, row_name, row_value FROM buh
                  UNION ALL
                      SELECT loc, loc_id, item_type_p, 2 as move_type, 'Приход всего' AS row_name, SUM(row_value)
                      FROM buh WHERE move_type=1
                      GROUP BY loc,loc_id,  item_type_p
                  UNION ALL
                      SELECT loc, loc_id, item_type_p, 4 as move_type, 'Расход всего' AS row_name, SUM(row_value)
                      FROM buh WHERE move_type=-1
                      GROUP BY loc,loc_id,  item_type_p 
                  UNION ALL(
                      select loc, loc_id, item_type, move_type, row_name, row_value from
                      (
                      select (loc||'
                  '||loc_name) loc, loc as loc_id,  'Приход всего' row_name, 0 row_value, 2 move_type from v_location_buh  l  where  l.loc in (select distinct location from buh)
                      union all    
                      select (loc||'
                  '||loc_name), loc as loc_id, 'Расход всего' row_name, 0 row_value, 4 move_type from v_location_buh  l  where  l.loc in (select distinct location from buh)
                  
                      )
                      cross join
                       (  select 'Товары' as item_type  from dual union all
                          select 'Материалы' from dual union all
                          select 'Спецодежда' from dual union all
                          select 'Тара' from dual ))
                  Ответить

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

Из-за тебя ушел bormand, guest!

    А не использовать ли нам bbcode?


    8