¿Es mala práctica usar SELECT * en producción?

Baking

Hola a todos, llevo poco tiempo trabajando como backend y tengo una duda recurrente. En mi equipo a veces usamos SELECT * FROM tabla para consultas simples porque "es más rápido al escribir". Pero he leído que en producción es una mala práctica. ¿Alguien me explica por qué? ¿Hay casos donde sí sea aceptable? También me interesa saber cómo afecta esto al rendimiento y a la seguridad. Gracias.

Snowboard

Hola, buena pregunta. Usar SELECT * es problemático por varias razones: 1) Puede traer columnas innecesarias, aumentando el tráfico de red y memoria. 2) Si la tabla cambia (nuevas columnas), tu código podría recibir datos inesperados. 3) En índices, puede forzar scans completos. Yo solo lo usaría en consultas ad-hoc o scripts de depuración, nunca en producción. Saludos.

Mixology

Estoy de acuerdo con lo anterior, pero añadiría que también hay un tema de mantenibilidad. Si usas SELECT * y luego renombras o eliminas una columna, tu aplicación puede romperse sin previo aviso. Es mejor ser explícito con las columnas que realmente necesitas. En cuanto a excepciones, tal vez en tablas con pocas columnas (3-4) y que sabes que no cambiarán, podría ser aceptable, pero es un riesgo innecesario.

Baking

Gracias por las respuestas. Entiendo el punto de las columnas extra y el mantenimiento. Pero, ¿qué pasa si la tabla tiene 30 columnas y necesito 28 de ellas? ¿Sigue siendo malo usar SELECT *? Porque escribir las 28 columnas es tedioso y propenso a errores.

Jewelry

Buen punto. Aunque sea tedioso, yo recomendaría listar las 28 columnas. Puedes usar herramientas como SHOW COLUMNS o tu IDE para generar la lista. Además, si siempre necesitas casi todas las columnas, quizás tu modelo de datos necesita una revisión (tal vez hay columnas que deberían estar en otra tabla). Otra opción es crear una vista que exponga solo las columnas necesarias. Pero ojo: select * es una bomba de tiempo.

Blues

Yo discrepo un poco. En ciertos contextos, como en un data warehouse donde las tablas son anchas pero estables, o en APIs internas donde el rendimiento no es crítico, usar SELECT * puede ahorrar tiempo de desarrollo. La clave es conocer tu dominio y tener control sobre los cambios en la BD. Pero en general, estoy de acuerdo en que es mejor evitarlo. Mi consejo: si decides usarlo, documenta por qué y pon una alerta si la tabla cambia.

Baking

Muy interesante, gracias a todos. Creo que adoptaré la práctica de listar las columnas, al menos para consultas en producción. Y para desarrollo rápido, usaré SELECT * pero con cuidado. ¡Gracias por los consejos!

TechFan

Lo de 'documentar por qué' es un parche, no una solución. Si usas SELECT * en un data warehouse, igual te comes cambios de esquema que rompen procesos ETL o reportes. Además, en APIs internas el rendimiento sí importa: transferir columnas innecesarias satura la red y aumenta latencia. La pereza de escribir columnas se paga caro en debug. Mejor usar una vista explícita o un DTO en la aplicación.