consulta - Alias de tabla SQL: ¿bueno o malo?
asignar alias consulta sql (17)
Siempre utilizo alias, ya que para obtener un rendimiento adecuado en MSSQL debe prefijar con el esquema en todo momento. Entonces verás muchas
Seleccione Person.Name From
dbo.Persona como persona
¿Cuáles son los pros y los contras de usar alias de tabla en SQL? Personalmente trato de evitarlos, ya que creo que hacen que el código sea menos legible (especialmente cuando se lee a través de declaraciones grandes y /), pero me gustaría escuchar cualquier contra-punto a esto. ¿Cuándo es generalmente una buena idea usar alias de tabla, y tiene algún formato preferido?
Bueno, hay algunos casos en que debes usarlos, como cuando necesitas unirte a la misma tabla dos veces en una consulta.
También depende de si tiene nombres de columna únicos en todas las tablas. En nuestra base de datos heredada tenemos prefijos de 3 letras para todas las columnas, provenientes de una forma abreviada de la tabla, simplemente porque un antiguo sistema de base de datos con el que alguna vez fuimos compatibles no era muy compatible con los alias de tablas.
Si tiene nombres de columna que aparecen en más de una tabla, especificar el nombre de la tabla como parte de la referencia de la columna es obligatorio, y por lo tanto un alias de tabla permitirá una sintaxis más corta.
El optimizador de consultas de Microsoft SQL se beneficia del uso de nombres completos o alias.
Personalmente prefiero los alias, y a menos que tenga muchas tablas, tienden a ser de una sola letra.
--seems pretty readable to me ;-)
select a.Text
from Question q
inner join Answer a
on a.QuestionId = q.QuestionId
También hay un límite práctico sobre cuánto tiempo se puede ejecutar una cadena Sql: los alias hacen que este límite sea más fácil de evitar.
Los alias de tabla son un mal necesario cuando se trata de esquemas altamente normalizados. Por ejemplo, y yo no soy el arquitecto en este DB, tengan paciencia conmigo, pueden tomar 7 uniones para obtener un registro limpio y completo que incluye el nombre, la dirección, el número de teléfono y la afiliación de la compañía.
En lugar de los alias de un solo carácter algo estándar, tiendo a favorecer los alias de palabras cortas, por lo que el SQL del ejemplo anterior termina pareciéndose a:
select person.FirstName
,person.LastName
,addr.StreetAddress
,addr.City
,addr.State
,addr.Zip
,phone.PhoneNumber
,company.CompanyName
from tblPeople person
left outer join tblAffiliations affl on affl.personID = person.personID
left outer join tblCompany company on company.companyID = affl.companyID
... etc
Los necesita si se va a unir a una mesa, o si usa la columna nuevamente en una subconsulta ...
Me gustan los nombres largos de tablas explícitas (no es raro tener más de 100 caracteres) porque utilizo muchas tablas y si los nombres no son explícitos, podría confundirme en cuanto a lo que guarda cada tabla.
Entonces, cuando escribo una consulta, tiendo a usar alias más cortos que tienen sentido dentro del alcance de la consulta y eso hace que el código sea mucho más legible.
Si escribo una consulta yo mismo (escribiendo en el editor y no usando un diseñador) siempre uso alias para el nombre de la tabla solo para que solo tenga que escribir el nombre completo de la tabla una vez.
Realmente odio leer las consultas generadas por un diseñador con el nombre completo de la tabla como un prefijo para cada nombre de columna.Siempre uso alias cuando escribo consultas. Generalmente trato de abreviar el nombre de la tabla a 1 o 2 letras representativas. Entonces, los usuarios se vuelven tú y debtor_transactions se convierte en dt, etc.
Ahorra en tipeo y todavía tiene algún significado.
Los nombres más cortos lo hacen más legible para mí también.
Siempre uso alias en mis consultas y es parte de la guía de códigos de mi empresa. En primer lugar, necesita alias o nombres de tabla cuando hay columnas con nombres idénticos en las tablas de unión. En mi opinión, los alias mejoran la legibilidad en consultas complejas y me permiten ver rápidamente la ubicación de cada columna. Incluso usamos alias con consultas de tabla única, porque la experiencia ha demostrado que las consultas de tabla única no permanecen en una sola tabla por mucho tiempo.
Supongo que lo único que realmente habla en contra de ellos es una abstracción excesiva. Si tiene una buena idea de a qué se refiere el alias (los buenos nombres ayudan; ''a'', ''b'', ''c'' pueden ser bastante problemáticos, especialmente cuando lee el enunciado meses o años después), no veo nada mal con aliasing
Como han dicho otros, las uniones requieren de ellos si está utilizando la misma tabla (o vista) varias veces, pero incluso fuera de esa situación, un alias puede servir para aclarar el propósito de una fuente de datos en un contexto particular. En el nombre del alias, intenta responder por qué estás accediendo a datos particulares, no cuáles son los datos.
Los alias son geniales si considera que mi organización tiene nombres de tabla como: NombreDeEsquema.NombreDePuntodeDatos_SubPoint_Sub-SubPoint_Sub-Sub-SubPoint ... Mi equipo usa un conjunto bastante estándar de abreviaturas, por lo que las conjeturas se minimizan. Tendremos que decir ProgramInformationDataPoint acortado a pidp, y las presentaciones a solo sub.
Lo bueno es que una vez que te pones en marcha de esta manera y la gente está de acuerdo, hace que esos archivos HAYUGE sean un poco más pequeños y fáciles de administrar. Al menos para mí, menos personajes para transmitir la misma información parece ir un poco más fácil en mi cerebro.
Si no usa un alias, es un error en su código que está esperando que ocurra.
SELECT Description -- actually in a
FROM
table_a a,
table_b b
WHERE
a.ID = b.ID
¿Qué sucede cuando hace algo como agregar una columna llamada Descripción a Table_B? Así es, obtendrás un error. Agregar una columna no necesita romper nada. Nunca veo escribir buen código, código libre de errores, como un mal necesario.
Bueno
Como se ha mencionado varias veces anteriormente, es una buena práctica escribir con un prefijo todos los nombres de columna para ver fácilmente qué columna pertenece a cada tabla, y los alias son más cortos que los nombres completos de la tabla para que la consulta sea más fácil de leer y comprender. Si usa un buen esquema de alias, por supuesto.
Y si crea o lee el código de una aplicación, que usa nombres de tablas generados externamente o generados dinámicamente, entonces sin alias es realmente difícil saber a primera vista qué representan todos esos "% s" u otros marcadores de posición. No es un caso extremo, por ejemplo, muchas aplicaciones web permiten personalizar el prefijo del nombre de la tabla en el momento de la instalación.
¿Soy la única persona aquí que realmente los odia?
En general, no los uso a menos que sea necesario. Odio tener que leer algo así como
select a.id, a.region, a.firstname, a.blah, b.yadda, b.huminahumina, c.crap
from table toys as a
inner join prices as b on a.blah = b.yadda
inner join customers as c on c.crap = something else
etc
Cuando leo SQL, me gusta saber exactamente qué estoy seleccionando cuando lo leo; los alias en realidad me confunden más porque tengo que recorrer líneas de columnas antes de llegar al nombre de la tabla, que generalmente representa información sobre los datos que no contiene el alias. Quizás esté bien si creó los alias, pero normalmente leo preguntas en con un código que parece usar alias sin una buena razón. (Además, a veces, alguien creará un alias en una declaración y simplemente no lo usará. ¿Por qué?)
Creo que los alias de tabla se usan mucho porque mucha gente es reacia a escribir. Aunque no creo que sea una buena excusa. Esa excusa es la razón por la que terminamos con nombres variables terribles, acrónimos de funciones terribles, código incorrecto ... Me tomaría el tiempo para escribir el nombre completo. Sin embargo, soy un tipo rápido, así que quizás eso tenga algo que ver con eso. (Tal vez en el futuro, cuando tenga el túnel carpiano, reconsideraré mi opinión sobre los alias.: P) Odio especialmente correr sobre alias de tabla en código PHP, donde creo que no hay absolutamente ninguna razón para hacerlo - ¡solo tienes que escribirlo una vez!
Siempre utilizo los calificadores de columna en mis declaraciones, pero no soy reacio a escribir mucho, por lo que gustosamente escribiré el nombre completo varias veces. (Por supuesto, utilizo incorrectamente la terminación de pestañas de MySQL). A menos que sea una situación en la que deba usar un alias (como algunos descritos en otras respuestas), la capa de abstracción adicional me resulta engorrosa e innecesaria.
Editar: (Más de un año después) Estoy lidiando con algunos procedimientos almacenados que usan alias (no los escribí y soy nuevo en este proyecto), y son un poco dolorosos. Me doy cuenta de que la razón por la que no me gustan los alias es por la forma en que están definidos. ¿Sabe que generalmente es una buena práctica declarar variables en la parte superior de su alcance? (¿Y generalmente al comienzo de una línea?) Los alias en SQL no siguen esta convención, lo que me hace rechinar los dientes. Por lo tanto, tengo que buscar en el código completo un alias único para saber dónde está (y lo que es frustrante es que tengo que leer la lógica antes de encontrar la declaración de alias). Si no fuera por eso, sinceramente, me gustaría que el sistema sea mejor.
Si alguna vez escribo un procedimiento almacenado que alguien más tendrá que tratar, pondré mis definiciones de alias en un bloque de comentarios al principio del archivo, como referencia. Honestamente, no puedo entender cómo ustedes no se vuelven locos sin eso.
¡ME ENCANTAN los alias! He hecho algunas pruebas al usarlas y no, y he visto algunas ganancias de procesamiento. Mi conjetura es que las ganancias de procesamiento serían mayores cuando se trata de conjuntos de datos más grandes y consultas complejas anidadas que sin. Si puedo probar esto, te lo haré saber.
En mi humilde opinión, realmente no importa con nombres de tablas cortas que tengan sentido, en ocasiones he trabajado en bases de datos donde el nombre de la tabla podría ser algo como VWRECOFLY o alguna otra cadena aleatoria (dictada por la política de la compañía) que realmente represente a los usuarios, por lo tanto En ese caso, encuentro que los alias realmente ayudan a que el código sea mucho más legible. (users.username hace mucho más sentido que VWRECOFLY.nombre de usuario)
Se requieren alias cuando se unen tablas con columnas que tienen nombres idénticos.