ANSI присоединится по сравнению с запросами СОЕДИНЕНИЯ не-ANSI, работают по-другому?
У длин тоже есть свои проблемы.
-
Длина занимает дополнительную память (не такая проблема сейчас, но большой фактор 30 лет назад).
-
Каждый раз, когда вы изменяете строку, вы должны обновлять длину, чтобы снизить производительность по всем направлениям.
-
С NUL-оканчивающейся строкой вы все равно можете использовать длину или сохранять указатель на последний символ, поэтому, если вы делаете много строковых манипуляций, вы все равно можете равняться производительности строки с длиной.
-
NUL-концевые строки намного проще - NUL-терминатор - это просто соглашение, используемое такими методами, как
strcat, для определения конца строки. Таким образом, вы можете хранить их в обычном массиве символов вместо использования структуры.
4 ответа
Эти два запроса идентичны, за исключением того, что второй - это синтаксис SQL ANSI-92, а первый - более старый синтаксис SQL, который не включает предложение соединения. Они должны производить точно такой же внутренний план запроса, хотя вы можете проверить его.
Вы должны использовать синтаксис ANSI-92 по нескольким причинам
- Использование предложения JOIN разделяет логика отношений из логика фильтра (ГДЕ) и, таким образом, чище и проще для понимания.
- Это не имеет значения для этого конкретного запроса, но есть несколько обстоятельств, когда старый синтаксис внешнего соединения (с использованием +) неоднозначен, и, следовательно, результаты запроса зависят от реализации - или запрос не может разрешиться вообще. Этого не происходит с ANSI-92
- . Это хорошая практика, так как большинство разработчиков и баз данных в настоящее время будут использовать ANSI-92, и вы должны следовать стандарту. Безусловно, все современные инструменты запросов будут генерировать ANSI-92.
- Как указывает @gbn, он имеет тенденцию избегать случайных перекрестных соединений.
Я сам некоторое время сопротивлялся ANSI-92, поскольку есть небольшое концептуальное преимущество для старый синтаксис как он есть Проще представить SQL как массовое декартово соединение всех используемых таблиц с последующей операцией фильтрации - мысленный прием, который может быть полезен для понимания того, что делает SQL-запрос. Однако несколько лет назад я решил, что мне нужно идти в ногу со временем, и после относительно короткого периода адаптации я теперь сильно предпочитаю это - преимущественно по первой причине, указанной выше. Единственное место, где следует отступить от синтаксиса ANSI-92 или, скорее, не использовать эту опцию, - это естественные соединения, которые неявно опасны.
The second construct is known as the "infixed join syntax" in the SQL community. The first construct AFAIK doesn't have widely accepted name so let's call it the 'old style' inner join syntax.
The usual arguments go like this:
Pros of the 'Traditional' syntax: the
predicates are physically grouped together in the WHERE clause in
whatever order which makes the query generally, and n-ary relationships particularly, easier to read and understand (the ON clauses of the infixed syntax can spread out the predicates so you have to look for the appearance of one table or column over a visual distance).
Cons of the 'Traditional' syntax: There is no parse error when omitting one of the 'join' predicates and the result is a Cartesian product (known as a CROSS JOIN in the infixed syntax) and such an error can be tricky to detect and debug. Also, 'join' predicates and 'filtering' predicates are physically grouped together in the WHERE clause, which can cause them to be confused for one another.
Выполните оба и проверьте их планы запросов. Они должны быть равными.
Два запроса равны - первый использует синтаксис, отличный от ANSI JOIN, второй - это синтаксис ANSI JOIN. Я рекомендую придерживаться синтаксиса ANSI JOIN.
И да, LEFT OUTER JOIN (которые, кстати, также являются синтаксисом ANSI JOIN) - это то, что вы хотите использовать, когда есть вероятность, что таблица, к которой вы присоединяетесь, может не содержать совпадающие записи.
Ссылка: Условные соединения в SQL Server