SQL: Select * El uso de

Duplicar posible:
Which is faster/best? SELECT * or SELECT column1, colum2, column3, etc.SQL: Select * El uso de

¿Es una mala práctica de utilizar Select *?

Estaba revisando un código antiguo y vi algunas sentencias 'SELECT *'. Mi compañero de trabajo anterior me había dicho que Select * era una mala práctica, pero realmente no podía ver el motivo (a menos que, por supuesto, solo tuviera que devolver algunos campos). Pero para la 'recuperación de detalles' completa (consultas de tipo Get by Id) Seleccione * parece correcto.

Fuente

2010-08-02 mint

Si necesita todos los detalles, utilice 'select *', especialmente si necesita columnas de detalles futuros de las que no conoce los nombres. –

No @ Lou Franco, esa es una práctica pobre incluso entonces. No sabes qué se agregará en el futuro. Es posible que tenga columnas que se agregaron con fines administrativos que no desea que los usuarios vean. Siempre es una mala práctica usar select *. Y definir las columnas suele ser mejor para el rendimiento, ya que la base de datos no tiene que buscarlas y, si tiene una unión, al menos una columna está duplicada, lo que significa que está desperdiciando ancho de banda devolviéndola. – HLGEM

Sí, se considera una mala práctica.

Es mejor especificar una lista de columnas explícita, especialmente si la tabla contiene muchas columnas y solo necesita algunas de ellas.

Fuente

2010-08-02 14:14:57

Incluso si es necesario seleccionar todas las columnas es aún mejor especificarlos en lugar de utilizar 'select *'

Fuente

2010-08-02 14:15:30 Giorgi

Si se producen cambios en el esquema (se añaden columnas adicionales), éstos serán atrapados por su aplicación. Esto podría ser indeseable, por ejemplo, si enlaza dinámicamente una grilla a un DataTable. También incurre en más sobrecarga en las comunicaciones de red.

Incluso si está seleccionando todas las columnas a partir de hoy, defina las columnas por nombre, es legible y explícito. Cualquier columna adicional no causará ningún problema con su código.

Fuente

2010-08-02 14:15:30

Es una mala práctica.

Si su esquema cambia más adelante, la aplicación que llama puede obtener más campos de los que no sabe qué hacer.

Además, obtiene más información de la que necesita, lo que afecta el rendimiento.

Además, implica que usted no sabe cuáles son las columnas.

Fuente

2010-08-02 14:15:45 JNK

Casi lo vi como una ventaja. Tengo que agregar un campo a mi tabla y ahora tengo que entrar en el código para cambiar la consulta SQL para el nuevo campo, en comparación con Seleccionar * no debería hacerse ningún cambio. – mint

@snow - Realmente deberías usar procs almacenados para llamar a esas cosas en lugar de SQL codificado, en cuyo caso cambias el proceso almacenado y todas tus llamadas se actualizan. – JNK

@snow, es una gran desventaja, puede exponer información al usuario que no desea que vean. Además, podría romper esto si alguno de ustedes decide reorganizar las columnas de la tabla (sí, hay idiotas que hacen esto) y ahora están insertando los datos del apellido en la columna del primer nombre y viceversa. Selct * es simplemente malo. – HLGEM

Usando SELECT * es una mala práctica por dos razones:

Puede recibir las columnas adicionales que no necesitas, desperdiciando el ancho de banda
Se puede romper su código si alguien añade una columna

Fuente

2010-08-02 14:16:12 SLaks

Sí, Seleccionar * es una mala práctica. Por un lado, no está claro para otros desarrolladores qué columnas realmente estás usando. ¿Estás realmente usando todos? ¿Qué sucede cuando agrega columnas? ¿Las está usando también? Eso hace que sea mucho más difícil refactorizar los nombres de columna si fuera necesario. En segundo lugar, hay algunos casos en que algunos sistemas de bases de datos recordarán qué columnas existían en el momento en que creó un objeto. Por ejemplo, si crea un procedimiento almacenado con Select *, se horneará en las columnas que existen en la tabla en el momento en que se compila. Si la tabla cambia, no refleja esos cambios en el procedimiento almacenado. Realmente no hay ninguna razón para usar Select * más allá de la pereza.

Fuente

2010-08-02 14:17:06 Thomas

Nunca había escuchado sobre el "horneado" de columnas usando select * en procedimientos almacenados ... notado sin embargo. – mint

Cuando usa SELECT *, opta por intercambiar la productividad inmediata (escribir una consulta más rápido) para la productividad de mantenimiento potencial (en caso de que su consulta subyacente cambie y rompa el código/consultas dependientes). La "maldad" de la práctica es una actividad de gestión de riesgos.

Fuente

2010-08-02 14:17:08 kbrimington

Respuesta

Cuestiones relacionadas