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

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

=*

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

*=

как сокращенное выражение для "левого внешнего соединения" в следующих выражениях:

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

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

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

Ответ 1

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

Ответ 2

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

выбор1:

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

Выбор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.

Ответ 3

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

Ответ 4

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

Ответ 5

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

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

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

Некоторые трюки, которые я нашел, были просто вопросами форматирования и пониманием того, что действительно требуется. Использование "INNER" и "OUTER" полностью избыточно и не требуется. Также я использую скобки, чтобы разграничить конец предложения соединения и поместить каждое условие в свою собственную строку:

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

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