Использование идентификаторов составных столбцов

Question

Я уверен, что это должно быть задокументировано ГДЕ-ТО, но на всю жизнь я просто не могу найти какую-либо документацию, объясняющую поведение.

Принимая 4 способа ссылки на таблицы (я неНе верьте, что есть еще, но не стесняйтесь исправлять меня):

1. Текущая база данных
2. Удаленная база данных
3. Связанный сервер
4. Синоним

Их поведение при использовании многоэлементных идентификаторов столбцов, кажется, отличается, и я пытаюсь понять причины этого. Я проверил различные типы операторов SELECT:

Текущая база данных

Работы

SELECT Column FROM Schema.Table;
SELECT Table.Column FROM Schema.Table;
SELECT Schema.Table.Column FROM Schema.Table;
SELECT Alias.Column FROM Schema.Table AS Alias;

Даже это работает! (Очевидно, только при использовании схемы dbo, но все же)

SELECT Schema.Table.Column FROM Table;

Удаленная база данных

Работает

SELECT Column FROM RemoteDB.Schema.Table;
SELECT Table.Column FROM RemoteDB.Schema.Table;
SELECT RemoteDB.Schema.Table.Column FROM RemoteDB.Schema.Table;
SELECT Alias.Column FROM RemoteDB.Schema.Table AS Alias;

Сбой

SELECT Schema.Table.Column FROM RemoteDB.Schema.Table;
The multi-part identifier "Schema.Table.Column" could not be bound.

Связанный сервер

Работает

SELECT Column FROM LinkedServer.RemoteDB.Schema.Table;
SELECT Table.Column FROM LinkedServer.RemoteDB.Schema.Table;
SELECT Alias.Column FROM LinkedServer.RemoteDB.Schema.Table AS Alias;

Fails

SELECT Schema.Table.Column FROM LinkedServer.RemoteDB.Schema.Table;
The multi-part identifier "Schema.Table.Column" could not be bound.

SELECT RemoteDB.Schema.Table.Column FROM LinkedServer.RemoteDB.Schema.Table;
The multi-part identifier "RemoteDB.Schema.Table.Column" could not be bound.

SELECT LinkedServer.RemoteDB.Schema.Table.Column FROM LinkedServer.RemoteDB.Schema.Table;
The multi-part identifier "LinkedServer.RemoteDB.Schema.Table.Column" could not be bound.
**I believe this fails are you're only allowed a maximum of 4 parts in the identifier?**
**Read this somewhere but nothing authoritive.  Would appreciate a reference.**

Синоним

Работает

SELECT Column FROM SynonymName;
SELECT Column FROM SynonymSchema.SynonymName;
SELECT SynonymName.ColumnName FROM SynonymSchema.SynonymName;
SELECT SynonymSchema.SynonymName.Column FROM SynonymSchema.SynonymName;
SELECT Alias.Column FROM SynonymSchema.SynonymName AS Alias;

Даже это работает! (Очевидно, только при использовании схемы dbo, но все же)

SELECT SynonymSchema.SynonymName.Column FROM SynonymName;

1. Я пытаюсь понять, почему определенные идентификаторы из нескольких частей работают, когда используются односторонне(например, схема для локального БД), но затем происходит сбой при использовании другого способа (например, схема для удаленного БД / связанного сервера).
2. Следует ли вам всегда использовать псевдонимы, чтобы гарантировать, что все будет работать всегда?

Любой совет будет высоко оценен, особенно указательs к официальной документации относительно причины разработки и рекомендаций по оптимальной практике для сценария «один размер подходит всем» (который в настоящее время я собираюсь предположить, чтобы быть маршрутом псевдонима).

Answer 1

Рекомендация. Псевдоним таблиц и использование идентификатора двух частей для имен столбцов. Первая часть - псевдоним таблицы, а вторая - имя столбца.

Почему? потому что:

• Использование одного идентификатора детали будет прервано, как только запрос содержит соединение (или применение), и это имя столбца будет принадлежать более чем одной таблице.

• Использование более двух идентификаторов частей для столбца заставит вас написать большую часть идентификатора дважды - один раз для столбца и один раз для таблицы. Если что-то меняется (например, таблица переместилась в другую схему, изменилось имя связанного сервера, изменился синоним), теперь вы должны изменить свой запрос (как минимум) в двух местах.

• Использование двухИдентификатор частей для столбца означает, что вы точно знаете, к какой таблице принадлежит этот столбец, и даже если вы добавите предложение join / apply или просто добавите столбец с тем же именем в одну из существующих таблиц в запросе, вы не сможетенужно поменять запрос вообще. Кроме того, теперь у вас есть только одно место, которое определяет, откуда берется таблица.

Самое главное - столбцы принадлежат таблицам. Они не принадлежат серверам, базам данных или схемам.

Обратите внимание, что таблица слов в этом ответе взаимозаменяема с представлением, табличной функцией, табличной переменной и т. Д.