Я только что читал об элементах NATURAL JOIN/USING - SQL92, которые (к сожалению?) отсутствуют в текущем репертуаре SQL Server.
Кто-нибудь пришел из СУБД, которая поддерживала их на SQL Server (или другую несуществующую СУБД), были ли они полезными, как они звучат, или банкой червей (что также звучит возможно!)?
Я никогда не использую NATURAL JOIN, потому что мне не нравится возможность того, что объединение может сделать что-то, чего я не намерен, потому что в обеих таблицах существует какое-то имя столбца.
Я иногда использую синтаксис USING join, но так же часто оказывается, что мне нужно более сложное условие соединения, чем USING может поддерживать, поэтому я все-таки преобразовываю его в эквивалентный синтаксис ON.
Вы считали бы СУБД, которая была действительно реляционной?:
в учебнике D [действительно реляционная язык], единственным оператором объединения является называется JOIN, и это означает "естественный присоединиться"... Не должно быть другого вида присоединиться... Немногие имели опыт использования надлежащего реляционный язык. Из тех, кто есть, я сильно подозреваю, что ни один из они когда-либо жаловались на некоторые воспринимаемые неудобства при спаривании столбцы в соответствии с их именами
Источник: " Значение имен столбцов" Хью Дарвен
Связанный вопрос SO: является NATURAL JOIN лучше, чем SELECT FROM WHERE с точки зрения производительности?
NATURAL JOIN - это не удобный ярлык: он просто опасен. Это довольно редко встречается в СУБД.
ИСПОЛЬЗОВАНИЕ явственно, но, учитывая его ограничения, вы не можете использовать его везде, поэтому ON будет согласованным, no?
Я не вижу значения синтаксиса USING или NATURAL - как вы столкнулись, только ON последовательно реализуется, поэтому лучше всего с точки зрения переносимости.
Быть явным также лучше для обслуживания, кроме того, альтернативы могут быть слишком ограниченными для решения ситуаций. Я также предпочел бы, чтобы моя кодовая база была последовательной.
Это вопрос удобства. Не обязательно, но он должен иметь свое место, например, в интерактивном запросе (каждое нажатие клавиши приближает нас к 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;
Теперь я могу сойти с ума и спорить, как это самый чистый способ выразить свое участие, и вы можете сразу начать добавлять дополнительные условия в предложение where, которое вам обычно нужно в любом случае, бла-бла-бла...
Таким образом, вы не должны пропустить этот особый синтаксис слишком дорого, но там нечего радоваться за то, что он этого не сделал ( "Фу, это было близко. Так хорошо, чтобы не ПРИСОЕДИНЯЙТЕСЬ ИСПОЛЬЗОВАТЬ. Мне было очень жаль" ).
Итак, хотя я лично использую JOIN ON 99% времени, я не чувствую, что Schadenfreude не существует JOIN USING или NATURAL JOIN.