Añadir un índice a las vistas en SQL-Server puede ser una buena idea para mejorar la velocidad de lectura en consultas sobre la misma, pero en determinados casos puede no ser recomendable ya que el mantenimiento de estos índices penaliza la velocidad en la inserción, borrado y actualización de datos. Me ha pasado que tras crear una vista con varios índices el funcionamiento de la aplicación empeoraba: ganaba dos segundos en la carga de datos pero perdía casi diez en la inserción.

¿En qué casos NO es recomendable crear índices sobre vistas?

• Sistemas OLTP con muchas operaciones de escritura.
• Bases de datos con múltiples actualizaciones.
• Consultas que no requieran de joins o de funciones de agregado.
• Consultas con agregación de datos con un alto grado de cardinalidad. (Es decir, que el conjunto de datos que devuelve la vista tenga prácticamente el mismo número de líneas que la tabla indizada)
• Vistas que tienen conjuntos de resultados que son más grandes que los datos originales en las tablas base.

Aquí os dejo un artículo muy interesante, en inglés, sobre el tema. Ya tiene unos años pero los consejos son igualmente válidos.

Habíamos visto dos técnicas para hacer un anti-join en SQL-Server sin recurrir al NOT IN(): la primera con un left join y comprobando qué campos vienen a nulo y la segunda con el operado EXCEPT. ¿Hay una tercera opción? Sí, la hay: NOT EXISTS(). Como recordaréis ya habíamos visto por aquí que EXISTS() es una función de SLQ-Server muy bien optimizada, y en este caso podemos usarla también.

Vamos a poner un ejemplo: Tenemos la tabla Oficinas y tenemos la tabla Empleados. Las oficinas tienen un campo IdOficina que las identifica, los empleados también tiene un campo IdOficina que nos dicen en qué oficina trabajan. Queremos sacar en una consulta qué oficinas no tienen empleado. Veamos la consulta:

Select 
  o.IdOficina
from 
  Oficinas o
where 
  NOT EXISTS 
    (Select * from Empleados e where e.IdOficina = o.IdOficina)

¿Cual de los tres métodos es mejor? La recomendación es que le pegues un ojo al plan de ejecución para que veas cual tiene un menor coste.

Te habrá pasado más de una vez: necesitas sacar todos los valores de la Tabla1 que no aparezcan en la Tabla2. Es decir, la operación opuesta a un INNER JOIN. En muchos casos vemos que hay quien usa un NOT IN() como solución:

Nota: Asumimos que las tablas están bien formadas y que la Tabla1 se relaciona con la Tabla2 por medio de una clave externa (en el ejemplo será el campo IdClaveExterna en Tabla2 que está relacionado con el campo id de Tabla1)

SELECT * FROM Tabla1 
WHERE Tabla1.id NOT IN (SELECT IdClaveExterna FROM Tabla2)

Y esto está mal. Muy mal. Porque el IN() tiene un rendimiento muy bajo, como hemos visto en el pasado, y su negación pues todavía ofrece uno peor. Entonces ¿cómo lo hacemos? No tenemos una unión que sea ANTI JOIN, pero lo podemos resolver de la siguiente forma ya que tenemos un campo Id en cada tabla para cada fila sirviendo como clave primaria:

SELECT * FROM Tabla1 
LEFT JOIN Tabla2 ON Tabla1.id = Tabla2.idClaveExterna
WHERE Tabla2.id IS NULL

De esta forma cogemos todos los valores de la Tabla1 unidos a la Tabla2 por la clave externa, pero descartando de la consulta aquellos valores que nos devuelvan nulo el valor de la clave primaria de la Tabla2.