Сокращенный синтаксис Transact-SQL?

Question

Я несколько раз замечал, что при работе с устаревшим кодом вы можете выполнять левое и правое внешние объединения в sql с помощью

=*

как сокращение от "правого внешнего соединения" и

*=

как сокращение от «левого внешнего соединения» в таких выражениях:

select table1.firstname, table2.lastname
from table1, table2
where table1.id *= table2.id

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

Я лично считаю, что операторы SQL, которые я видел с помощью этих операторов, сложнее понять, чем при использовании прописанного синтаксиса, так есть ли какие-то преимущества в использовании сокращенной версии?

Answer 1

= * и * = не являются претензиями к текущим стандартам SQL, я думаю, что эти операторы будут устаревшими в ближайшее время, вы всегда должны использовать стандартный синтаксис соединения Другие операторы, о которых вы говорите, сбивают с толку и должны уйти, я смущаюсь, когда вижу их в объектах базы данных.

Answer 2

Причина, по которой он имеет непредвиденные последствия, заключается в том, что он интерпретирует предложение ENTIRE where как предложение JOIN. Пример:

выбор1:

select * from table a left join table b on a.id=b.id
     where b.name = "hello world"

VS

Выбор2:

select * from table a left join table b on a.id=b.id and b.name = "hello world"

Эти 2 выбора возвращают разные результаты. Когда вы пишете заявление, как это:

select * from tablea,tableb where tablea.id *= tableb.id and b.name="hello world"

Я ожидаю, что большинство людей ХОЧУ результаты из Select1 ... но вы на самом деле получите результаты из Select2.

Answer 3

Если вы используете SQL Server, ни при каких обстоятельствах никогда не используйте этот синтаксис. Бывают случаи, когда возвращаются неверные результаты, поскольку иногда SQL-сервер правильно интерпретирует это как внешнее соединение, а иногда этот синтаксис интерпретирует как перекрестное соединение. Поскольку результирующие наборы этих двух элементов существенно различаются, вы никогда не сможете положиться на результаты использования этого синтаксиса. Кроме того, SQL Server 2008 является последней версией SQl Server, которая даже разрешит использование sysntax.

Answer 4

Я бы не использовал синтаксис * = или = (+), поскольку они несовместимы с другими СУБД или даже в случае с MSSQL Server, совместимым с более поздними версиями, если вы не включите низкие уровни совместимости. Тогда действительно беспокоит то, что в какой-то момент MS просто полностью откажется от поддержки.

Мне потребовалось некоторое время, чтобы привыкнуть к изменению моих "старых" привычек ... Я предпочел синтаксис * =, потому что его было меньше печатать и объединять с более простым потоком равных объединений (которые все еще действительны и приемлемы) *

Одним из моих возражений против перехода на использование JOINS была вся эта печать и путаница, которую я обнаружил в примерах запросов, использующих их.

Некоторые хитрости, которые я обнаружил, были просто проблемы с форматированием и знание того, что действительно требуется. Использование «ВНУТРЕННИХ» и «ВНЕШНИХ» полностью избыточно и не нужно. Кроме того, я использую скобки, чтобы разделить конец предложения соединения и поместить каждое условие в отдельную строку:

FROM blah b LEFT JOIN blah2 b2 ON (b.ID = b2.ID)
LEFT JOIN blah3 b3 ON (b.ID = b3.ID)
...

Некоторые говорят, что синтаксис ANSI JOIN сложнее испортить, потому что при равных соединениях легко пропустить параметр соединения ... На практике у меня было больше трудностей, когда я забыл сказать «ГДЕ», а интерпретатор все еще думал Я определяю условия соединения, а не условия поиска, которые могут привести к всевозможным трудным для поиска / странностям результатам.

Answer 5

Мое личное мнение (после 6+ лет работы в SQL & TSQL) заключается в том, что этот унаследованный стиль только усложняет понимание кода другими разработчиками, не разбирающимися в унаследованном синтаксисе. Я всегда предпочитаю более подробный и описательный синтаксис, если производительность не снижается - вы никогда не знаете, когда вам придется передать поддержку этого кода:)