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

    −158

    1. 1
    2. 2
    3. 3
    4. 4
    SELECT ft_login,fi_system,ft_password,fk_id
    FROM users u
    INNER JOIN taccountscontent t ON u.id = t.fk_id
    WHERE u.id IN (select id from users where id=123)

    Оригинал http://www.askdev.ru/question/16663/%D0%97%D0%B0%D0%BF%D1%80%D0%BE%D1%81-%D0%BA-%D0%91%D0%94-%D0%B8-%D1%86%D0%B8%D0%BA%D0%BB-While/

    Запостил: et, 13 Сентября 2012

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

    • Я чего-то не понимаю... Сколько значений может вернуть выражение в скобках?
      Ответить
      • Если поле id - PK, то 1.
        Сам запрос вернет то, что надо:

        create table #tbl(i int);
        insert into #tbl(i) values (1)
        insert into #tbl(i) values (2)
        insert into #tbl(i) values (3)
        select * from #tbl where i In (select i from #tbl where i=1)
        drop table #tbl
        i
        -----------
        1

        (1 row(s) affected)

        Возможно, мускул как-то реагирует по-другому?
        Говно просто в том, что автор запроса совсем не дружит с SQL.
        Хорошо, что ядро СУБД понимает и такое говно.
        Ответить
        • У меня нехорошее предчувствие, что на следующий вопрос сможет ответить только кэп, поэтому спрячу его под спойлер.
          Четвёртая строка во всех ситуациях эквивалентна WHERE u.id = 123 ?
          Ответить
    • Никогда не понимал людей, явно указывающих вид джойна. Или в каких-то СУБД обычный - не внутренний?
      Ответить
      • раз на раз не приходится, как я понимаю
        Ответить
      • Да вроде по стандарту JOIN без параметров был INNER JOIN'ом... но могу ошибаться.
        Ответить
        • Пожалуй, что да. Тогда это или неуверенные люди, или просто привыкли копипастить. Я за всё моё время, когда мне приходилось писать запросы, никогда не писал слов "inner" и "outer".
          Ответить
          • > Тогда это или неуверенные люди, или просто привыкли копипастить.
            Вот полистал немного SQL-92:
            If a <qualified join> is specified and a <join type> is not specified, then INNER is implicit.
            <join type> ::= INNER | <outer join type> [ OUTER ] | UNION
            <outer join type> ::= LEFT | RIGHT | FULL


            > Я за всё моё время, когда мне приходилось писать запросы, никогда не писал слов "inner" и "outer".
            Аналогично.
            Ответить
      • >>> Да вроде по стандарту JOIN без параметров был INNER JOIN'ом... но могу ошибаться.

        Да, но только в контексте MySQL, а в некоторых других, мелкософтовском, постгре и пр.. там лучше указать явно, я не помню в каких именно и что там не нравится ядру, но лучше всегда указывать явно какой джойн ты юзаешь, так и переносимость кода повысится, если на другую БД сьехать приспичит.
        Ответить
        • > Да вроде по стандарту
          > Да, но только в контексте MySQL
          С каких пор стандарт SQL-92 рассматривается в контексте MySQL? Если бы я это вычитал в MySQL, я бы так и сказал.

          PostgreSQL: The words INNER and OUTER are optional in all forms. INNER is the default; LEFT, RIGHT, and FULL imply an outer join.

          По MsSQL документального обоснования не нашел, но у них у самих в некоторых примерах в документации JOIN записан без INNER.

          SQLite тоже понимает JOIN как INNER JOIN.

          В Oracle тоже допустим вариант без INNER.

          Приведите базу, в которой JOIN по дефолту является не INNER JOIN, и тогда я соглашусь с вами, что его нужно писать всегда (и, конечно, обзову эту базу нестандартным говном, т.к. в SQL-92 черным по белому написано, что If a <qualified join> is specified and a <join type> is not specified, then INNER is implicit).
          Ответить
          • В мускуле JOIN, CROSS JOIN, и INNER JOIN эквивалентны.
            http://dev.mysql.com/doc/refman/5.0/en/join.html
            In MySQL, JOIN, CROSS JOIN, and INNER JOIN are syntactic equivalents (they can replace each other). In standard SQL, they are not equivalent. INNER JOIN is used with an ON clause, CROSS JOIN is used otherwise.
            Ответить
            • JOIN без типа и без ON в стандарте не описан вообще, поэтому юзать его нежелательно, и следует заменить его на явный CROSS JOIN.

              А правило про то, что JOIN ... ON эквивалентно INNER JOIN ... ON здесь соблюдено. Поэтому при наличии ON я имею право опустить INNER.

              Выпендреж MySQL в данном случае не ломает код, и INNER не нужен.
              Ответить
              • ОРЛЫ? Читаем стандарт внимательней:
                a) If NATURAL is specified, then a <join specification> shall
                              not be specified.
                
                            b) If UNION is specified, then neither NATURAL nor a <join spec-
                              ification> shall be specified.
                Ответить
        • Если менять базу - всё равно переписывать запросы.
          Ответить
          • > Если менять базу - всё равно переписывать запросы.
            Два чаю этому сэру. Проблемы с совместимостью начнутся уже на таких простых вещах, как манипуляции со строками и датами.
            Ответить
        • 3) If a <qualified join> is specified and a <join type> is not
                      specified, then INNER is implicit.
          Ответить
          • Спасибо, но я эту фразу тут цитировал уже 2 раза ;)
            Ответить
            • действительно, два раза
              а очем вообще спор?

              ман - хорошо, а стандарт - лучше
              может получится переносимым среди ANSI-\d?\d?\d\d-compliant хранилищ
              Ответить
      • Явное указание INNER подчеркивает, что человек действительно ПОНИМАЕТ, какой вид резьбового соединения он делает. У новичков оно хоть как-то в мозгу прорисует два круга Эйлера с заштрихованной областью на их пересечении.
        Так же, когда идет множество различных джойнов, условия ON (при хорошем форматировании и примерно одинаковой длине имен таблиц) находятся на одном уровне. Как следствие, читабельность кода увеличивается.
        Ответить
        • Тарасоформатирование спасёт нас всех.
          Ответить
    • Ну просто специалист по быстродействию.
      Ответить

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