Каков правильный синтаксис в SQL Server для адресации таблиц?

Это кажется довольно очевидным вопросом, но я не смог придумать правильный термин для того, что я пытаюсь спросить, поэтому придумать справочный материал для этого было сложно. Хотя ответы кажутся очевидными.

При изучении учебного материала по Pluralsight для SQL Server они рекомендовали всегда ссылаться на таблицы как в "обычном", так и в обычном режиме. запросы (то, что вы могли бы написать для базового веб-сервиса) и для запроса SQL, возможно, в хранимой процедуре, например:

<code>[databasename].[dbo].[some_table].[sometimesacolumngoeshere]
</code>

Хотя я обнаружил, что очень часто можно встретить хранимые процедуры и т. Д., Которые просто используют:

<code>my_column    or    [my_column]
</code>

Разница здесь в том, что очевидно, что каждый предоставляет абсолютный «адрес»; явно, тогда как другой неявный.

Как вы узнаете, когда уместно использовать один над другим, а также как вы это называете, обращаясь?

Я предпочел бы, чтобы всегда было явно, и если вам нужно сэкономить место и / или сделать вещи более понятными, вы можете указать псевдоним для полного полного & quot; адреса & quot ;, правильно?

Ответы на вопрос(7)

SQL Server состоит из четырех частей:

Most often you reference an object by name

SELECT * FROM MyTable

Then you can specify the owner or schema of the object:

SELECT * FROM dbo.MyTable

Then you can reference the database that the object lives in:

SELECT * FROM master.dbo.MyTble

Finally you can reference the table on a different server

SELECT * FROM test1.master.dbo.MyTable

Это объясняется лучше, чем я могу наMSDN

 05 апр. 2012 г., 19:03
Хммм, я должен расследовать.
 05 апр. 2012 г., 19:06
Небольшая разница:stackoverflow.com/questions/1112374/…
 05 апр. 2012 г., 19:01
Вы должны использовать хотя бы схему, есть разница в производительности.
 05 апр. 2012 г., 19:41

В большинстве случаев я бы всегда советовал использовать полный адрес, чтобы быть в безопасности.

    [databasename].[dbo].[some_table].[sometimesacolumngoeshere]

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

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

НАПРИМЕР

   FROM [databasename].[dbo].[some_table].[sometimesacolumngoeshere] SOME

   SELECT SOME.Name

На объекты можно ссылаться через один или несколько идентификаторов.

Вы можете использовать один идентификатор для ссылки на объект, но если идентификатор неоднозначный, вы должны использовать больше идентификаторов для уникальной идентификации объекта.

Например, две таблицы с именемTableA существующие в разных схемах должны ссылаться в запросе, используя как минимум два идентификатора,schema_one.TableA а такжеschema_two.TableA.

Там естьСтраница MDSN где вы можете узнать больше об именах и идентификаторах объектов.

Что касается использования нескольких идентификаторов для имен объектов, если вы более конкретны, вы уменьшаете неоднозначность в запросах и ускоряете синтаксический анализ запроса, поскольку ядру базы данных не приходится решать проблемы неоднозначности за счет читабельности запросы.

Мои личные предпочтения (для наиболее часто используемых объектов) - это использованиеschema.Table при ссылках на таблицы иcolumn, если в запросе указана одна таблица, иtable.column если в запросе указано несколько таблиц

 05 апр. 2012 г., 19:03
Категорически не согласен
 05 апр. 2012 г., 19:06
Вот почему я говорю, что это субъективно и является вопросом предпочтения. ;-)

Многогранность не права.

Учитывая пример хранимой процедуры, которая использует полностью определенное имя, которое ссылается на объекты в одной и той же базе данных, вот еще две причины, чтобы не полностью квалифицировать таким образом:

If you have a stored procedure that refers to an object in the same database, it will break if you rename your database.

If you were to start using Visual Studio database tools to add your database scripts to source control, you get lots of warnings to deal with

Это хорошая идея, чтобы понять и использоватьschemas должным образом

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

Решение Вопроса

Ты прав. Обычно SQL пытается найти искомое поле & quot; my_column & quot; во всех таблицах в ваших разделах FROM и JOIN. Однако, если у вас есть «my_column» в таблице A и в таблице B вам необходимо явно указать, какой & quot; my_column & quot; Вы ищете, включая имя таблицы. Это идет вверх по цепочке к dbo и databasename, если у вас там тоже есть коллизии.

В большинстве случаев вы обнаружите, что люди явно не вызывают таблицы, в которых находится столбец, если они не объединяют несколько таблиц.

Например, я пишу свои запросы так:

SELECT a.field1, b.field2
FROM tableA AS a
INNER JOIN tableB AS b ON a.id = b.a_id
WHERE a.id = 123

Здесь я использую AS для псевдонима tableA и tableB, чтобы сделать их более читаемыми a и b. Я мог бы так же легко написать свой запрос так:

SELECT tableA.field1, tableB.field2
FROM tableA
INNER JOIN tableB ON tableA.id = tableB.a_id
WHERE tableA.id = 123

Или вот так, если field1 и field2 уникальны для этих таблиц, но это немного сбивает с толку относительно того, откуда поступает каждая часть данных.

SELECT field1, field2
FROM tableA
INNER JOIN tableB ON tableA.id = tableB.a_id
WHERE tableA.id = 123
 05 апр. 2012 г., 19:15
Я не могу с этим не согласиться. Использование псевдонимов таблиц, безусловно, помогает уменьшить беспорядок и, тем не менее, дает необходимую подсказку, чтобы определить, из какой таблицы поступает поле, просто взглянув на запрос. +1 тебе.

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

С точки зрения читабельности, я утверждаю, что он является явным ТОЛЬКО при необходимости. Довольно часто операторы SQL достаточно сложны без необходимости читать много ненужного текста.

я думаю что

SELECT TOP 1000 [StoreNumber]
      ,[Address1]
      ,[Address2]
      ,[City]
      ,[St]
      ,[Zip]
      ,[ZipSuffix]
      ,[LocationType]
      ,[LocationSubType]
      ,[Corp]
      ,[Division]
      ,[ZoneNumber]
      ,[DistrictNumber]
      ,[StateNumber] 
  FROM [CommonData].[dbo].[vw_StoreData]

много более читабельным, чем

SELECT TOP 1000 [CommonData].[dbo].[vw_StoreData].[StoreNumber]
      ,[CommonData].[dbo].[vw_StoreData].[[Address1]
      ,[CommonData].[dbo].[vw_StoreData].[[Address2]
      ,[CommonData].[dbo].[vw_StoreData].[[City]
      ,[CommonData].[dbo].[vw_StoreData].[[St]
      ,[CommonData].[dbo].[vw_StoreData].[[Zip]
      ,[CommonData].[dbo].[vw_StoreData].[[ZipSuffix]
      ,[CommonData].[dbo].[vw_StoreData].[[LocationType]
      ,[CommonData].[dbo].[vw_StoreData].[[LocationSubType]
      ,[CommonData].[dbo].[vw_StoreData].[[Corp]
      ,[CommonData].[dbo].[vw_StoreData].[[Division]
      ,[CommonData].[dbo].[vw_StoreData].[[ZoneNumber]
      ,[CommonData].[dbo].[vw_StoreData].[[DistrictNumber]
      ,[CommonData].[dbo].[vw_StoreData].[[StateNumber] 
  FROM [CommonData].[dbo].[vw_StoreData]

(Это ухудшается, когда вы начинаете объединять таблицы, и еще хуже, если вы объединяете таблицы в разных базах данных.)

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

Но в SQL Server, например, вы сможете открыть этот запрос в конструкторе и увидеть его в гораздо более удобном графическом представлении.

ИМХО, единственный раз, когда я бы использовал полный синтаксисwhen necessaryпри пересечении границ таблицы / базы данных / схемы или если у вас есть две таблицы с одним и тем же именем поля.

Пример:

SELECT TOP 1000 [CommonData].[dbo].[vw_StoreData].[StoreNumber]
      ,[Address1]
      ,[Address2]
      ,[City]
      ,[St]
      ,[Zip]
      ,[ZipSuffix]
      ,[LocationType]
      ,[LocationSubType]
      ,[Corp]
      ,[Division]
      ,[ZoneNumber]
      ,[DistrictNumber]
      ,[StateNumber] 
  FROM [CommonData].[dbo].[vw_StoreData]
  Inner Join [CommonData].[dbo].[vw_StorePhones]
   ON [CommonData].[dbo].[vw_StorePhones].[StoreNumber] = [CommonData].[dbo].[vw_StoreData].[StoreNumber]

И даже в этом случае я бы использовалНастольные псевдонимы сократить его и сделать его более читабельным.

Все это говорит о том, что в реальном мире весьма вероятно, что вы окажетесь в компании, которая уже определилась со стандартным форматом, и вам потребуется кодировать в соответствии со стандартом компании.

 05 апр. 2012 г., 19:03
Категорически не согласен
 05 апр. 2012 г., 19:06
Вот почему я говорю, что это субъективно и является вопросом предпочтения. ;-)

Ваш ответ на вопрос