Usar SELECT * en una vista de SQL Server no es una buena práctica. Esa frase la hemos escuchado muchas veces y, en términos generales, es correcta. El problema aparece cuando la explicación se queda en la superficie y deja una idea equivocada: que una vista definida con SELECT * se comporta como si el asterisco se resolviera dinámicamente cada vez que consultamos la vista.
No funciona así. Y precisamente por eso el tema es más interesante de lo que parece.
Cuando creamos una vista con SELECT *, SQL Server no guarda una especie de comodín vivo que siempre representa “todas las columnas actuales de la tabla”. Durante la creación de la vista, el motor resuelve ese *, determina qué columnas existen en ese momento y almacena metadatos asociados a la vista. Es decir, aunque el texto de la definición pueda seguir mostrando SELECT *, la vista ya tiene una lista de columnas asociada internamente.
Ese matiz es importante porque cambia por completo la forma en la que debemos entender el riesgo. El problema no es solo que SELECT * lea más columnas de las necesarias. En una vista, además, puede generar inconsistencias entre lo que creemos que hemos definido, lo que existe en la tabla base y lo que realmente devuelve la vista.
¿Qué ocurre al crear una vista con SELECT * en SQL Server?
Vamos a partir de un ejemplo sencillo pero suficiente para ver el problema de cerca. Supongamos que creamos una tabla y después una vista usando SELECT *.
CREATE TABLE dbo.Clientes
(
ClienteID int NOT NULL,
Nombre varchar(100) NOT NULL,
Email varchar(200) NULL
);
GO
CREATE VIEW dbo.vClientes
AS
SELECT *
FROM dbo.Clientes;
GOA simple vista parece que la vista representa todas las columnas de dbo.Clientes. Y en este momento concreto, eso es cierto. Si consultamos la vista, veremos ClienteID, Nombre y Email.
Pero SQL Server no interpreta ese * como una promesa dinámica de futuro. En el momento de crear la vista, el motor resuelve qué columnas forman parte de ella y guarda esa información en sus metadatos. Podemos comprobarlo consultando sys.columns.
SELECT
c.column_id,
c.name,
t.name AS tipo_dato,
c.max_length
FROM sys.columns AS c
JOIN sys.types AS t
ON c.user_type_id = t.user_type_id
WHERE c.object_id = OBJECT_ID('dbo.vClientes')
ORDER BY c.column_id;Ahí veremos las columnas que SQL Server tiene asociadas a la vista. No estamos viendo directamente las columnas actuales de la tabla base, sino la metadata de la vista como objeto.
Esto es lo que muchas explicaciones simplifican demasiado. El SELECT * no queda “vivo” en el sentido que muchos imaginan. La vista tiene una estructura persistida. Y cuando la tabla base cambia, esa estructura no se actualiza automáticamente solo porque nos parezca lógico. SQL Server no está aquí para cumplir nuestras expectativas emocionales, por suerte para él.
SELECT * en vistas de SQL Server al añadir columnas
El primer caso es el más habitual: añadimos una columna nueva a la tabla base.
ALTER TABLE dbo.Clientes
ADD Telefono varchar(20) NULL;
GO
SELECT *
FROM dbo.vClientes;Mucha gente esperaría ver ahora cuatro columnas: ClienteID, Nombre, Email y Telefono. Pero no será así. La vista seguirá devolviendo las columnas que tenía asociadas cuando se creó. La nueva columna existe en la tabla, pero no aparece en la vista.
Aquí el problema es que no suele haber un error al ejecutar la vista. La consulta funciona. Y precisamente por eso el problema es peligroso: no rompe nada de forma evidente. Simplemente tenemos una discrepancia entre lo que parece decir la definición y lo que realmente devuelve el objeto.
Si miramos el texto de la vista, podemos seguir viendo algo como esto:
SELECT * FROM dbo.Clientes;Pero si miramos las columnas de la vista en sys.columns, veremos que Telefono no forma parte de la metadata de la vista. La definición textual y la estructura efectiva del objeto ya no transmiten la misma idea. Magnífico, otra fuente de confusión silenciosa, como si no tuviéramos suficientes.
Para actualizar la metadata de una vista no enlazada a esquema podemos usar sp_refreshview.
EXEC sp_refreshview 'dbo.vClientes';
GO
SELECT * FROM dbo.vClientes;Después de refrescar la vista, SQL Server vuelve a resolver la definición y actualiza sus metadatos. En ese momento la nueva columna puede aparecer. Pero eso no convierte SELECT * en una buena idea. Solo demuestra que la vista necesitaba una actualización explícita para alinear su metadata con la tabla base.
SELECT * en vistas de SQL Server al eliminar columnas
El segundo caso es más agresivo: eliminamos una columna que formaba parte de la vista cuando se creó.
ALTER TABLE dbo.Clientes
DROP COLUMN Email;
GO
SELECT *
FROM dbo.vClientes;Aquí el resultado puede ser un error al consultar la vista, porque la metadata de la vista sigue esperando una columna que ya no existe en la tabla base. Hemos cambiado el objeto del que depende la vista, pero la vista mantiene una definición interna que ya no puede resolverse correctamente.
Este punto es importante porque desmonta otra idea muy extendida: que las vistas nos protegen automáticamente de los cambios en las tablas base. No. Una vista es un objeto dependiente. Si cambiamos la tabla que hay debajo, podemos romper la vista, igual que podemos romper un procedimiento almacenado, una función o una consulta de aplicación. Realmente sería el mismo problema que si hubiéramos definido las columnas en el SELECT.
La diferencia es que con SELECT * el problema puede quedar más escondido. Cuando escribimos las columnas explícitamente, vemos con claridad qué dependencias existen. Si una vista usa Email, sabemos que borrar Email rompe esa vista. Con SELECT *, esa dependencia queda disfrazada detrás de un comodín aparentemente inocente.
Y, como casi todo lo que aparenta inocencia en bases de datos, tarde o temprano acaba en una incidencia.
¿Por qué las columnas explícitas son mejores en una vista?
Cuando escribimos una vista así, el contrato queda claro:
CREATE VIEW dbo.vClientes
AS
SELECT
ClienteID,
Nombre,
Email
FROM dbo.Clientes;
GOAquí no hay interpretación creativa. La vista devuelve esas columnas porque esas son las columnas que hemos decidido exponer. Si añadimos Telefono a la tabla base, la vista no lo devuelve. Pero eso ya no es una inconsistencia, es el comportamiento esperado. La vista representa un contrato concreto, no una puerta abierta a todo lo que aparezca en la tabla.
Si eliminamos Email, la vista fallará igualmente, pero el motivo será evidente. La definición dice que necesita Email y la columna ya no existe. No hay un * ocultando la dependencia real. El código expresa la intención.
Ese es el verdadero valor de listar columnas explícitamente. No se trata solo de rendimiento, aunque también. Se trata de legibilidad, mantenimiento, seguridad y estabilidad del contrato.
Una vista no debería ser “todo lo que haya en esta tabla”. Una vista debería representar una proyección concreta de datos con un propósito concreto. Si no sabemos qué columnas queremos devolver, probablemente tampoco sabemos muy bien para qué estamos creando la vista. Y en SQL Server eso suele acabar en una colección de objetos heredados que nadie se atreve a tocar, ese museo del terror que todas las empresas llaman “modelo de datos”.
SELECT * en vistas de SQL Server y seguridad
También hay un ángulo de seguridad que suele ignorarse. Si usamos vistas para exponer solo parte de la información de una tabla, SELECT * es especialmente mala idea.
Imaginemos que una tabla de clientes no contiene inicialmente información sensible. Creamos una vista con SELECT * y damos permisos sobre esa vista. Más adelante, alguien añade una columna con información que no debería exponerse a todos los usuarios.
Si la vista no se refresca, quizá esa columna no aparezca inmediatamente. Pero si en algún momento se ejecuta sp_refreshview, se altera la vista o se recrea, esa nueva columna podría acabar expuesta sin que nadie haya revisado conscientemente el contrato de seguridad.
Con columnas explícitas, este riesgo baja muchísimo. Añadir una columna nueva a la tabla no la expone automáticamente en la vista si esta se refresca. Para incluirla, alguien tiene que modificar la definición y escribirla. Ese pequeño acto de intención es importante. En seguridad, los cambios implícitos son una receta estupenda para que un lunes cualquiera empiece con reuniones desagradables.
SCHEMABINDING: cuando queremos bloquear el contrato
Si queremos ir un paso más allá, podemos crear la vista con WITH SCHEMABINDING.
CREATE VIEW dbo.vClientes
WITH SCHEMABINDING
AS
SELECT
ClienteID,
Nombre,
Email
FROM dbo.Clientes;
GOCon SCHEMABINDING, SQL Server impide cambios en las tablas base que afecten a la vista mientras esa dependencia exista. No podremos eliminar una columna usada por la vista sin modificar antes la vista. Tampoco podremos usar SELECT *. Hay que escribir las columnas de forma explícita y usar nombres de objetos cualificados con esquema.
Esto no significa que todas las vistas deban llevar SCHEMABINDING. Depende del caso. Pero cuando una vista actúa como contrato estable para aplicaciones, informes, integraciones o seguridad, merece la pena considerarlo.
Además, las vistas indexadas requieren SCHEMABINDING, precisamente porque SQL Server necesita garantías fuertes sobre la estabilidad de la definición. No puede materializar resultados de una consulta cuyo esquema se mueve alegremente como si estuviera en una reunión de requisitos sin cerrar.
El verdadero problema de SELECT * en vistas de SQL Server
La recomendación “no uses SELECT *” es correcta, pero se queda corta si no explicamos el mecanismo interno.
En consultas ad hoc, SELECT * ya tiene problemas conocidos: lee columnas innecesarias, aumenta tráfico de red, puede empeorar operaciones intermedias y acopla el código al esquema completo de la tabla. Pero en vistas añadimos otro problema: la metadata persistida de la vista puede quedar desalineada respecto a la tabla base.
Al añadir columnas, la vista puede no reflejar los cambios. Al eliminar columnas, puede fallar. Y en todos los casos el origen del problema es el mismo: estamos usando un comodín en un objeto que debería tener un contrato estable.
Por eso la buena práctica no debería formularse solo como “usa columnas explícitas porque es más mantenible”. Deberíamos decir algo más preciso: en una vista, SELECT * se resuelve en el momento de crear o refrescar el objeto, no cada vez que lo consultamos como muchos esperan. Esa diferencia explica los errores, las inconsistencias y los sustos.
Conclusión
SELECT * en una vista de SQL Server no es simplemente una mala costumbre estética. Es una forma de esconder dependencias, debilitar el contrato de la vista y crear una falsa sensación de dinamismo que no existe.
Cuando creamos una vista, SQL Server almacena metadata sobre sus columnas. Si después cambia la tabla base, esa metadata puede quedar desactualizada. Añadir columnas puede no reflejarse en la vista. Eliminar columnas puede romperla.
La solución razonable es escribir siempre las columnas explícitamente, entender la vista como un contrato y usar SCHEMABINDING cuando necesitemos proteger ese contrato frente a cambios accidentales. No se trata de obedecer una regla de buenas prácticas porque sí. Se trata de entender cómo SQL Server interpreta realmente nuestra definición.
Y ahí está la diferencia entre repetir “no uses SELECT *” como un mantra y saber explicar por qué, que casualmente es donde empiezan las buenas decisiones técnicas.
