SQL Server - отсутствие NATURAL JOIN/x JOIN y USING (поле)

Question

Я только что читал об элементах NATURAL JOIN/USING - SQL92, которые (к сожалению?) Отсутствуют в текущем репертуаре SQL Server.

Кто-нибудь пришел из СУБД, которая поддерживала их на SQL Server (или другую несуществующую СУБД) - были ли они полезными, как они звучат, или банкой червей (что также звучит возможно!)?

Answer 1

Я никогда не использую NATURAL JOIN, потому что мне не нравится возможность того, что соединение может сделать что-то, чего я не намерен, потому что в обеих таблицах существует какое-то имя столбца.

я использовать USING присоединиться синтаксис иногда, но так же, как часто получается, что мне нужно более сложное условие соединения, чем USING может поддерживать, поэтому я преобразовать его в эквивалентный ON синтаксис в конце концов.

Answer 2

Я не вижу значения синтаксиса USING или NATURAL - по мере того как вы столкнулись, последовательно выполняется только ON, поэтому это лучше всего с точки зрения переносимости.

Быть явным также лучше для обслуживания, кроме того, альтернативы могут быть слишком ограниченными для решения ситуаций. Я также предпочел бы, чтобы моя кодовая база была последовательной.

Answer 3

Связанного SO вопрос: is NATURAL JOIN any better than SELECT FROM WHERE in terms of performance ?

ПРИРОДНЫХ РЕГИСТРИРУЙТЕСЬ не удобный ярлык: это просто опасно. В СУБД это довольно редко.

ИСПОЛЬЗОВАНИЕ ЯВЛЯЕТСЯ явным, но учитывая его ограничения, вы не можете использовать его везде, поэтому ON будет последовательным, нет?

Answer 4

Считаете ли вы СУБД, которая была действительно реляционная ?:

в Tutorial D [действительно реляционная языка], единственный оператор «присоединиться» является называется JOIN, а это означает, что «естественный присоединиться «... Не должно быть другого типа of join ... Немногие имели опыт использования правильного реляционного языка . Из тех, кто есть, я сильно подозреваю, что ни один из им никогда не жаловался некоторым воспринимаемой неудобства в спаривание столбцов в соответствии с их именами

Источник: «The Importance of Column Names» Хью Дарвен

Answer 5

Это вопрос удобства. Не обязательно, но он должен иметь свое место, например, в интерактивном запросе (каждое нажатие клавиши приближает нас к RSI) или некоторые простые случаи ручного написания SQL даже в производственном коде (да, я это написал. И даже видел JOIN USING в серьезном коде, написанном мудрыми программистами, кроме меня. Но я отвлекаюсь).

Я нашел этот вопрос при поиске подтверждения того, что SS отсутствует эта функция, и я ее получил. Меня только смущает количество ненависти против этого синтаксиса, которое я отношу к синдрому Sour Grapes. Я чувствую себя забавно, когда читаю лекции с покровительственным тоном Сладости (читай: синтаксический сахар) плохо для вашего здоровья. Вы все равно не нуждаетесь в этом.

Что приятно в синтаксисе JOIN USING, является то, что он работает не только на именах столбцов, но и на псевдонимов столбцов, например:

-- foreign key "order".customerId references (customer.id) 
SELECT c.*, c.id as customerId, o.* from customer c 
join "order" o using (customerId); 

Я не согласен с «Присоединиться к использованию будет лучше, если только (...)». Или аргумент, что вам могут потребоваться более сложные условия. С другой точки зрения, зачем использовать JOIN ON? Почему бы не быть чистым и не переместить все условия в статью WHERE?

SELECT t1.*, t2.* from t1, t2 where t2.t1_id = t1.id; 

теперь я мог сойти с ума и спорить, как это чистый способ выразить присоединиться, и вы можете сразу же начать добавлять больше условий в пункте где, что вы обычно нужно в любом случае, бла-бла-бла ..

Поэтому вы не должны пропустить этот особый синтаксис слишком дорого, но нечего радоваться за его отсутствие («Фу, это было близко. Так хорошо, что не нужно ПРИСОЕДИНИТЬСЯ ИСПОЛЬЗОВАТЬ. боли ").

Итак, в то время как я лично использую JOIN ON 99% времени, я не чувствую, что нет Schadenfreude, когда нет JOIN USING или NATURAL JOIN.