Cuándo usar SQL Table Alias ​​

Question

Tengo curiosidad por saber cómo las personas usan alias de tabla. Los otros desarrolladores donde trabajo siempre utilizan los alias de tabla, y siempre utiliza el alias de a, b, c, etc.

He aquí un ejemplo:

SELECT a.TripNum, b.SegmentNum, b.StopNum, b.ArrivalTime 
FROM Trip a, Segment b 
WHERE a.TripNum = b.TripNum 

no estoy de acuerdo con ellos, y pensar alias de tabla debe usarlo con moderación

Creo que deberían usarse cuando se incluye la misma tabla dos veces en una consulta, o cuando el nombre de la tabla es muy largo y usar un nombre más corto en la consulta facilitará la lectura de la consulta.

También creo que el alias debe ser un nombre descriptivo en lugar de solo una letra. En el ejemplo anterior, si sentía que necesitaba usar un alias de tabla de 1 letra, usaría t para la tabla de Disparo ys para la tabla de segmento.

Answer 1

Considero que debe utilizarlos con la mayor frecuencia posible, pero estoy de acuerdo en que t & s representan las entidades mejor que & b.

Esto se reduce a, al igual que todo lo demás, las preferencias. Me gusta que pueda depender de sus procedimientos almacenados siguiendo las mismas convenciones cuando cada desarrollador usa el alias de la misma manera.

Vaya a convencer a sus compañeros de trabajo de estar en la misma página que usted o esto no tiene ningún valor. La alternativa es que podría tener una tabla Zebra como primera tabla y alias como a. Eso sería lindo.

Answer 2

Los uso para ahorrar mecanografía. Sin embargo, siempre uso letras similares a la función. Entonces, en su ejemplo, escribiría:

SELECT t.TripNum, s.SegmentNum, s.StopNum, s.ArrivalTime 
FROM Trip t, Segment s 
WHERE t.TripNum = s.TripNum 

Eso simplemente lo hace más fácil de leer, para mí.

Answer 3

Siempre. Hazlo un hábito.

Answer 4

Yo sólo uso cuando son necesarios para distinguir qué tabla un campo proviene de

select PartNumber, I.InventoryTypeId, InventoryTypeDescription 
from dbo.Inventory I 
    inner join dbo.InventoryType IT on IT.InventoryTypeId = I.InventoryTypeId 

En el ejemplo anterior ambas tablas tienen un campo InventoryTypeId, pero los otros nombres de campo son únicos.

Utilice siempre una abreviatura de la tabla como nombre para que el código tenga más sentido; pregunte a los otros desarrolladores si nombran sus variables locales A, B, C, etc.

La única excepción es en los raros casos en que la sintaxis de SQL requiere un alias de tabla pero no se hace referencia, p.

select * 
from (
    select field1, field2, sum(field3) as total 
    from someothertable 
) X 

En lo anterior, la sintaxis SQL requiere que el alias de la tabla de la subselección, pero no se hace referencia en cualquier lugar, así que conseguir X perezosa y utilización o algo por el estilo.

Answer 5

Como regla general siempre los uso, ya que generalmente hay múltiples uniones en mis procedimientos almacenados. También lo hace más fácil cuando se usan herramientas de generación de código como CodeSmith para que genere automáticamente el nombre de alias.

Intento alejarme de las letras individuales como & b, ya que puedo tener varias tablas que comiencen con la letra aob. Voy con un enfoque más largo, la concatenación de la clave foránea referenciada con la tabla de alias, por ejemplo, CustomerContact ... este sería el alias de la tabla Customer al unirse a una tabla de contactos.

La otra razón por la que no me importa más larga nombre, es debido a que la mayoría de mis procedimientos almacenados se están generando a través del código CodeSmith. No me importa teclear el pocos que tendré que construir yo mismo.

Usando el ejemplo actual, me gustaría hacer algo como:

SELECT TripNum, TripSegment.SegmentNum, TripSegment.StopNum, TripSegment.ArrivalTime 
FROM Trip, Segment TripSegment 
WHERE TripNum = TripSegment.TripNum 

Answer 6

Hay dos razones para utilizar alias de tabla.

El primero es cosmético. Las declaraciones son más fáciles de escribir y, tal vez, también más fáciles de leer cuando se usan alias de tabla.

El segundo es más sustantivo. Si una tabla aparece más de una vez en la cláusula FROM, necesita alias de tabla para mantenerlos diferenciados. Las autouniones son comunes en los casos en que una tabla contiene una clave externa que hace referencia a la clave principal de la misma tabla.

Dos ejemplos: una tabla de empleados que contiene una columna de ID de supervisor que hace referencia al ID del empleado del supervisor.

La segunda es una explosión de partes. A menudo, esto se implementa en una tabla separada con tres columnas: ComponentPartID, AssemblyPartID y Quantity. En este caso, no habrá ninguna unión automática, pero a menudo habrá una combinación de tres vías entre esta tabla y dos referencias diferentes a la tabla de Partes.

Es un buen hábito para entrar.

Answer 7

No me parece más que una preferencia. Como se mencionó anteriormente, los alias guardan tipeo, especialmente con nombres largos de tabla/vista.

Answer 8

Usando el nombre completo hace que sea más difícil de leer, especialmente para las consultas de mayor tamaño o la Orden/Producto/OrderProduct scenari0

que haría uso de t y s. O O/P/op

Si utiliza SCHEMABINDING continuación, las columnas deben estar calificados de todas formas

Si se agrega una columna a una tabla base, entonces la calificación reduce la posibilidad de un duplicado en la consulta (por ejemplo, una Columna "Comentario")

Debido a esta calificación, tiene sentido siempre usar alias.

El uso de a y b es una obediencia ciega a un estándar extraño.

Answer 9

lo uso siempre, razones:

• salen nombres de las tablas llenas de declaraciones las hace difícil de leer, además de que no puede tener una misma mesa dos veces
• no usar nada es una muy mala idea, porque más adelante se podría añadir algún campo a una de las mesas que ya está presente en alguna otra mesa

Considere este ejemplo:

select col1, col2 
from tab1 
join tab2 on tab1.col3 = tab2.col3 

Ahora, imagine unos meses más tarde, decide agregar la columna llamada 'col1' a tab2. La base de datos le permitirá silenciosamente hacer eso, pero las aplicaciones se romperían al ejecutar la consulta anterior debido a la ambigüedad entre tab1.col1 y tab2.col1.

embargo, estoy de acuerdo con usted en la nomenclatura: a, b, c está bien, pero t y s sería mucho mejor en su ejemplo. Y cuando tengo la misma tabla más de una vez, usaría t1, t2, ... o s1, s2, s3 ...

Answer 10

Una cosa que he aprendido es que especialmente con consultas complejas; es mucho más sencillo solucionarlo seis meses después si usa el alias como calificador para cada referencia de campo. Entonces no estás tratando de recordar de qué mesa proviene ese campo.

Tendemos a tener algunos nombres de tabla ridículamente largos, por lo que me resulta más fácil leer si las tablas tienen alias. Y, por supuesto, debes hacerlo si estás usando una tabla derivada o una autocombinación, por lo que estar en el hábito es una buena idea. Encuentro que la mayoría de nuestros desarrolladores terminan usando el mismo alias para cada tabla en todos sus sps, así que la mayoría de las veces cualquier persona que lo lea sabrá de inmediato qué es el alias pug o mmh.

Answer 11

Siempre los uso. Anteriormente solo los usaba en consultas que involucraban solo una tabla, pero luego me di cuenta de que a) las consultas que involucran solo una tabla son raras, yb) las consultas que involucran solo una tabla raramente permanecen así por mucho tiempo. Así que siempre los puse desde el principio para que yo (u otra persona) no tenga que adaptarlos posteriormente. Ah, y por cierto: yo los llamo "nombres de correlación", de acuerdo con el estándar SQL-92 :)

Answer 12

Tablas alias deberían ser cuatro cosas:

1. corto
2. significativo
3. utilizado siempre
4. Usado consistentemente

Por ejemplo, si tiene tablas llamadas service_request, service_provider, user y affiliate (entre muchas otras) una buena práctica sería aliar esas tablas como "sr", "sp", "u" y "a", y hacerlo en cada consulta posible. Esto es especialmente conveniente si, como suele ser el caso, estos alias coinciden con los acrónimos utilizados por su organización. Entonces, si "SR" y "SP" son los términos aceptados para la Solicitud de servicio y el Proveedor de servicio, respectivamente, los alias anteriores tienen una doble carga útil de forma intuitiva tanto para la tabla como para el objeto de negocio que representa.

Los defectos obvios con este sistema son primero que puede ser incómodo para los nombres de tabla con muchas "palabras", p. a_long_multi_word_table_name que alias a almwtn o algo así, y que es probable que termines con tablas nombradas de tal manera que abrevian el mismo.El primer defecto se puede tratar como quiera, por ejemplo tomando las últimas 3 o 4 letras, o cualquier subconjunto que considere más representativo, más exclusivo o más fácil de escribir. El segundo que encontré en la práctica no es tan problemático como podría parecer, tal vez solo por la suerte. También puede hacer cosas como tomar la segunda letra de una "palabra" en la tabla, como aliasing account_transaction a "atr" en lugar de "at" para evitar conflictos con account_type.

Por supuesto, si utiliza el enfoque anterior o no, los alias deben ser cortos porque los va a escribir con mucha frecuencia, y siempre se deben usar porque una vez que ha escrito una consulta contra una sola tabla y se omite el alias, es inevitable que luego deba editar en una segunda tabla con nombres de columna duplicados.

Answer 13

En consultas simples, no uso alias. En las consultas de la pizca de varias tablas que siempre los uso porque:

• hacen consultas más legible (mis alias son 2 o más letras mayúsculas que es un acceso directo para el nombre de tabla y si es posible una relación a otros tablas)
• permiten rápido desarrollo y reescritura (mis nombres de tabla son largas y tienen prefijos dependiendo del papel que representan)

así que en vez de, por ejemplo:

SELECT SUM(a.VALUE) 
     FROM Domesticvalues a, Foreignvalues b 
     WHERE a.Value>b.Value 
     AND a.Something ... 

escribo:

select SUM(DVAL.Value) 
     from DomesticValues DVAL, ForeignValues FVAL 
     where DVAL.Value > FVAL.Value 
     and DVAL.Something ... 

Answer 14

¿Puedo añadir a un debate que ya tiene varios años?

Hay otra razón por la que nadie ha mencionado. El analizador SQL en ciertas bases de datos funciona mejor con un alias. No puedo recordar si Oracle cambió esto en versiones posteriores, pero cuando se trataba de un alias, buscaba las columnas en la base de datos y las recordaba. Cuando se trataba de un nombre de tabla, incluso si ya se encontraba en la declaración, volvía a verificar la base de datos para las columnas. Entonces, usar un alias permite un análisis más rápido, especialmente de sentencias SQL largas. Estoy seguro de que alguien sabe si este es todavía el caso, si otras bases de datos hacen esto en el momento de análisis, y si cambió, cuando cambió.

Answer 15

Hay muchas buenas ideas en los mensajes anteriores acerca de cuándo y por qué para alias nombres de tablas. Lo que nadie más ha mencionado es que también es beneficioso para ayudar a un mantenedor a comprender el alcance de las tablas. En nuestra empresa no tenemos permitido crear vistas. (Gracias al DBA). Por lo tanto, algunas de nuestras consultas se vuelven grandes, incluso excediendo el límite de 50,000 caracteres de un comando SQL en Crystal Reports. Cuando una consulta alias sus tablas como a, b, c, y una subconsulta de eso hace lo mismo, y múltiples subconsultas en cada una de ellas usan los mismos alias, es fácil confundirse con el nivel de la consulta que se está leyendo. Esto incluso puede confundir al desarrollador original cuando haya pasado el tiempo suficiente. Usar alias únicos dentro de cada nivel de una consulta facilita su lectura porque el alcance permanece claro.