inner - mysql alias select

Cuándo usar SQL Table Alias (15)

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

Aquí hay 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 creo que los alias de la tabla deberían usarse 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 el uso de un nombre más corto en la consulta facilitará la lectura de la consulta.

También creo que el alias debería 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.

¿Puedo agregar 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ó, cuándo cambió.

Como regla general , siempre los uso , ya que generalmente hay varias 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 a & b, ya que puedo tener varias tablas que comienzan con la letra a o b. 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 el nombre más largo , se debe a que la mayoría de mis procedimientos almacenados se están generando a través del código CodeSmith. No me importa escribir las pocas que tendré que construir.

Usando el ejemplo actual, haría algo como:

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

En consultas simples, no uso alias. En consultas con múltiples tablas siempre las uso porque:

hacen que las consultas sean más legibles (mis alias son 2 o más letras mayúsculas que son un atajo para el nombre de la tabla y, de ser posible, una relación con otras tablas)
permiten un desarrollo y una reescritura más rápidos (los nombres de mi tabla son largos y tienen prefijos según el rol que representen)

así que en lugar de, por ejemplo:

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

Yo escribo:

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

Hay dos razones para usar 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.

El segundo 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.

Hay muchas buenas ideas en los mensajes anteriores sobre cuándo y por qué alias los nombres de las 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.

Las alias de tablas deben ser cuatro cosas:

Corto
Significativo
Siempre usado
Usado consistentemente

Por ejemplo, si tuviera 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 tablas con muchas "palabras", por ejemplo, a_long_multi_word_table_name, que alias a almwtn o algo así, y que es probable que termines con tablas nombradas tales 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 usa el enfoque anterior o no, los alias deben ser cortos porque los va a escribir con mucha frecuencia, y siempre deben usarse porque una vez que ha escrito una consulta contra una sola tabla y se ha omitido el alias, es Es inevitable que luego deba editar en una segunda tabla con nombres de columna duplicados.

Lo uso siempre, razones:

dejar los nombres completos de las tablas en las declaraciones hace que sean difíciles de leer, además de que no se puede tener una misma tabla dos veces
no usar nada es una muy mala idea, porque más tarde podrías agregar un campo a una de las tablas que ya está presente en alguna otra tabla

Considera este ejemplo:

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

Ahora, imagine unos meses más tarde, decide agregar una 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.

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

Los uso para guardar la escritura. Sin embargo, siempre uso letras similares a la función. Entonces, en tu ejemplo, escribiría:

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

Eso solo hace que sea más fácil de leer, para mí.

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

Siempre. Hazlo un hábito.

Siento que debes usarlos con la mayor frecuencia posible, pero estoy de acuerdo en que las t & s representan las entidades mejor que a & b.

Esto se reduce a, como todo lo demás, 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 todo esto es inútil. La alternativa es que podría tener una tabla Zebra como primera tabla y alias como a. Eso sería lindo.

Una cosa que aprendí 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.

Usar el nombre completo hace que sea más difícil de leer, especialmente para consultas más grandes o el pedido / Producto / ProductoProducción scenari0

Yo usaría t y s. O o / p / op

Si usa SCHEMABINDING, las columnas deben calificarse de todos modos

Si 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.

Usar ayb es una obediencia ciega a un estándar extraño.

Yo 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: los llamo "nombres de correlación", según el estándar SQL-92 :)

solo los uso cuando son necesarios para distinguir de qué tabla proviene un campo

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 casos excepcionales en los que la sintaxis de SQL requiere un alias de tabla pero no se hace referencia, por ejemplo

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

En lo anterior, la sintaxis de SQL requiere el alias de la tabla para la subselección, pero no se hace referencia en ninguna parte, así que me pongo vago y uso X o algo así.