¿Cuál es la sintaxis correcta en SQL Server para las tablas de direccionamiento?

Question

Esto parece una pregunta bastante obvia, pero no he podido pensar en el término adecuado para lo que estoy tratando de preguntar, por lo que encontrar material de referencia para esto ha sido complicado. Las respuestas parecen obvias, sin embargo.

Al examinar el material de entrenamiento Pluralsight para SQL Server, recomendaron consultar siempre tablas tanto en consultas "regulares" (algo que podría escribir para un servicio web básico) como para consultas SQL en un procedimiento almacenado, como el siguiente:

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

Aunque he encontrado que es muy común encontrarse con procedimientos almacenados, etc., que sólo tiene que utilizar:

my_column or [my_column] 

La diferencia aquí es, obviamente, que uno ofrece una "dirección" absoluta explícitamente , mientras que el ot ella está implícita.

¿Cómo sabe cuándo es apropiado usar uno sobre el otro, y también cómo lo llama, dirigiéndose?

Mi preferencia sería siempre ser explícito, y si necesita ahorrar espacio y/o dejar las cosas más claras, podría alias una "dirección" completa explícita, ¿correcto?

Answer 1

Estás en la correcta. Básicamente SQL intentará encontrar el campo que está buscando "my_column" en todas las tablas en sus secciones FROM y JOIN. Sin embargo, si tiene una "mi_columna" en la tabla A y en la tabla B, debe indicar explícitamente qué "mi_columna" está buscando incluyendo el nombre de la tabla. Esto sube la cadena a dbo y databasename si tienes colisiones allí también.

La mayoría de las veces encontrará que las personas no indican explícitamente las tablas en las que se encuentra una columna a menos que se unan a varias tablas.

Por ejemplo escribo mis preguntas como esta:

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

Aquí estoy usando el AS a tablaA alias y TableB a una más legible y b. Podría haber la misma facilidad escrito mi consulta como esta:

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

O como esto, si campo1 y campo2 son exclusivos de ahí tablas, pero esto se hace un poco confuso en cuanto a donde cada dato está viniendo.

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

Answer 2

SQL Server tiene cuatro nombres de las piezas:

• mayoría de las veces se hace referencia a un objeto por su nombre

  SELECT * FROM MyTable 
  

• A continuación, puede especificar el propietario o esquema del objeto:

  SELECT * FROM dbo.MyTable 
  

• Luego puede hacer referencia a la base de datos en la que vive el objeto:

  SELECT * FROM master.dbo.MyTble 
  

• Finalmente, puede hacer referencia a la tabla en un servidor diferente

  SELECT * FROM test1.master.dbo.MyTable 
  

Se explica mejor que yo en MSDN

Answer 3

Creo que esta es una de esas preguntas que subjetivo , y se convertirá en una cuestión de preferencia, pero:

Desde una perspectiva de legibilidad, yo argumentaría por ser explícita SOLAMENTE cuando sea necesario. Muy a menudo, las sentencias de SQL son lo suficientemente complejas sin tener que leer una gran cantidad de texto innecesario.

creo que

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

es mucho más fácil de leer que

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] 

(Se pone peor cuando se inicia mesas de unión, y aún peor si se está uniendo a las tablas en diferentes bases de datos.)

puedo ver dónde se podría argumentar que la segunda es más fácil de leer si lo que necesita saber exactamente qué base de datos, el esquema y tabla de un campo en particular proviene de mirando a la consulta solo.

Pero en SQL Server, por ejemplo, podría abrir esa consulta en un diseñador y verla en una vista gráfica mucho más amigable.

en mi humilde opinión, la única vez que me gustaría utilizar la sintaxis completa es cuando sea necesario, al cruzar las fronteras de mesa/base de datos/esquema, o si usted tiene dos tablas con el mismo nombre de campo.

Ejemplo:

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] 

E incluso en ese caso, que haría uso de Table Aliases para acortarlo y que sea más legible.

Dicho todo esto, en el mundo real, es muy probable que se encuentre trabajando para una empresa que ya ha decidido el formato estándar, y deberá codificar de acuerdo con los estándares de la compañía.

Answer 4

Si bien es posible utilizar los nombres de implicto para las columnas, es una mala elección desde el punto de vista de facilidad de mantenimiento. Nunca pongo código de producción que no alía todas las columnas porque, cuando retrocedes un año más tarde para cambiar ese informe o consulta, realmente no quieres tener que averiguar en cuál de las 20 tablas te uniste. Además, no especificar hace que la base de datos trabaje más para encontrar la columna y tiene más errores de codificación donde tiene los nombres de columna que son iguales en dos tablas sin referencia. Es un buen hábito estar usando referencias explícitas.

Answer 5

Los objetos se pueden consultar a través de uno o varios identificadores.

Puede usar un único identificador para referirse a un objeto, pero si el identificador es ambiguo, debe usar más identificadores para identificar de manera única el objeto.

Por ejemplo, dos tablas denominadas TableA existente en diferentes esquemas deben estar referenciados en el uso de una consulta al menos un dos identificadores, schema_one.TableA y schema_two.TableA.

Hay un MDSN page donde puede encontrar más información sobre los nombres e identificadores de los objetos.

En cuanto al uso de varios identificadores para nombres de objeto, si es más específico, reduce la ambigüedad en las consultas y acelera el análisis de la consulta, ya que el motor de base de datos no tiene que resolver problemas de ambigüedad, al costo de legibilidad de las consultas.

Mi preferencia personal (para los objetos más utilizados) está utilizando schema.Table tablas cuando se hace referencia y column, si se refiere a una sola tabla en la consulta, y table.column si se hace referencia a varias tablas en la consulta.

Answer 6

Pluralsight son incorrectos.

Teniendo en cuenta el ejemplo de un procedimiento almacenado que utiliza un nombre completo que se refiere a los objetos en la misma base de datos, aquí hay dos razones más para no calificar totalmente de esa manera:

• Si usted tiene una procedimiento almacenado que se refiere a un objeto en la misma base de datos, se romperá si cambia el nombre de su base de datos.

• Si se va a empezar a utilizar herramientas de bases de datos de Visual Studio para agregar secuencias de comandos de base de datos de control de código fuente, se obtiene gran cantidad de advertencias para hacer frente a

Es una buena idea para comprender y utilizar esquemas adecuadamente

Answer 7

En la mayoría de los casos yo siempre aconsejo utilizar la dirección completa sólo para estar seguro

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

Sin embargo, esto solo es realmente necesario cuando tiene múltiples bases de datos. Solo he encontrado uno o dos problemas al seleccionar las bases de datos, y esto generalmente se soluciona seleccionando el correcto en el servidor sql.

Una vez que está realmente dentro de una consulta y le ha dado a la tabla un alias abreviado, entonces realmente no hay necesidad de incluir la dirección completa porque ya está referenciada.

por ejemplo

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

    SELECT SOME.Name