- 1
- 2
- 3
- 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)
Нашли или выдавили из себя код, который нельзя назвать нормальным, на который без улыбки не взглянешь? Не торопитесь его удалять или рефакторить, — запостите его на говнокод.ру, посмеёмся вместе!
−158
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/
inkanus-gray 13.09.2012 15:23 # 0
DBdev 13.09.2012 15:44 # 0
Сам запрос вернет то, что надо:
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.
Хорошо, что ядро СУБД понимает и такое говно.
inkanus-gray 14.09.2012 12:25 # +1
Четвёртая строка во всех ситуациях эквивалентна WHERE u.id = 123 ?
eth0 13.09.2012 17:29 # +1
Lure Of Chaos 13.09.2012 17:41 # 0
bormand 13.09.2012 18:12 # 0
eth0 13.09.2012 19:35 # +1
bormand 13.09.2012 20:01 # 0
Вот полистал немного 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".
Аналогично.
deep 17.09.2012 11:33 # 0
Да, но только в контексте MySQL, а в некоторых других, мелкософтовском, постгре и пр.. там лучше указать явно, я не помню в каких именно и что там не нравится ядру, но лучше всегда указывать явно какой джойн ты юзаешь, так и переносимость кода повысится, если на другую БД сьехать приспичит.
bormand 17.09.2012 12:54 # +1
> Да, но только в контексте 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).
Vasiliy 17.09.2012 16:04 # 0
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.
bormand 17.09.2012 16:18 # +1
А правило про то, что JOIN ... ON эквивалентно INNER JOIN ... ON здесь соблюдено. Поэтому при наличии ON я имею право опустить INNER.
Выпендреж MySQL в данном случае не ломает код, и INNER не нужен.
guest 18.09.2012 08:46 # 0
eth0 17.09.2012 21:12 # +2
bormand 17.09.2012 21:51 # 0
Два чаю этому сэру. Проблемы с совместимостью начнутся уже на таких простых вещах, как манипуляции со строками и датами.
guest 18.09.2012 00:40 # 0
bormand 18.09.2012 05:27 # 0
guest 18.09.2012 08:52 # 0
а очем вообще спор?
ман - хорошо, а стандарт - лучше
может получится переносимым среди ANSI-\d?\d?\d\d-compliant хранилищ
DBdev 19.09.2012 15:16 # 0
Так же, когда идет множество различных джойнов, условия ON (при хорошем форматировании и примерно одинаковой длине имен таблиц) находятся на одном уровне. Как следствие, читабельность кода увеличивается.
eth0 20.09.2012 09:14 # +2
infolex 13.02.2013 14:12 # 0