¿Cuáles son las desventajas de usar vistas SQLServer?

Una posible desventaja de usar vistas es que abstrae la complejidad del diseño subyacente que puede conducir a abusos por parte de desarrolladores junior y creadores de informes.

Para un proyecto particularmente grande y complejo diseñé un conjunto de vistas que iban a ser utilizadas principalmente por los diseñadores de informes para poblar crystal reports. Descubrí semanas más tarde que los desarrolladores junior habían comenzado a usar estas vistas para buscar agregados y unirse a estas vistas ya grandes simplemente porque estaban allí y estaban fácil de consumir. (Había un fuerte elemento de diseño de EAV en la base de datos. Me enteré de esto después de que los desarrolladores junior comenzaron a preguntar por qué los informes aparentemente simples tomaban muchos minutos en ejecutarse.

La eficiencia de una vista depende en gran parte de las tablas subyacentes. La vista realmente es una forma organizada y consistente de ver los resultados de las consultas. Si la consulta utilizada para formar la vista es buena y utiliza índices adecuados en las tablas subyacentes, la vista no debería afectar negativamente al rendimiento.

En SQL Server también puede crear vistas materializadas o indexadas (desde SQL Server 2000), que aumentan un poco la velocidad.

También uso vistas regularmente. Una cosa a tener en cuenta, sin embargo, es que usar muchas vistas podría ser difícil de mantener si sus tablas subyacentes cambian con frecuencia (especialmente durante el desarrollo).

EDITAR: Dicho esto, encuentro que la conveniencia y la ventaja de poder simplificar y reutilizar consultas complejas supera el problema de mantenimiento, especialmente si las vistas se usan de manera responsable.

Las vistas pueden perjudicar el rendimiento cuando la vista contiene lógica, columnas, filas o tablas que la consulta final no utiliza en última instancia. No puedo decirte cuántas veces he visto cosas como:

SELECT ... 
FROM (View with complex UNION of ActiveCustomer and InactiveCustomer tables)
WHERE Active = True 

(filtrando así todas las filas que se incluyeron en la vista desde la tabla InactiveCustomer), o

SELECT (one column)
FROM (view that returns 50 columns)

(SQL tiene que recuperar muchos datos que luego se descartan en un paso posterior. Es posible que esas otras columnas sean caras de recuperar, como a través de un marcador búsqueda), o

SELECT ...
FROM (view with complex filters)
WHERE (entirely different filters)

(es probable que SQL podría haber utilizado un índice más apropiado si las tablas se consultaron directamente), o

SELECT (only fields from a single table)
FROM (view that contains crazy complex joins)

(mucha sobrecarga de CPU a través de la unión, y E / s innecesarias para las lecturas de la tabla que luego se descartan), o mi favorito:

SELECT ...
FROM (Crazy UNION of 12 tables each containing a month of data)
WHERE OrderDate = @OrderDate

(Lee 12 tablas cuando realmente solo necesita leer 1).

En la mayoría de los casos, SQL es lo suficientemente inteligente como para "ver a través de las cubiertas" y llegar a un plan de consulta eficaz de todos modos. Pero en otros en cada una de las situaciones anteriores, la respuesta fue eliminar la vista y consultar las tablas subyacentes en su lugar.

Al menos (incluso si cree que SQL sería lo suficientemente inteligente como para optimizarlo de todos modos), eliminar la vista a veces puede hacer que su propia depuración y optimización de consultas sea más fácil (un poco más obvio lo que hay que hacer).

Un inconveniente de las vistas que he encontrado es una inmersión en el rendimiento al incorporarlas en consultas distribuidas. Este SQLMag artículo discute - y mientras uso datos altamente artificiales en la demostración, me he encontrado con este problema una y otra vez en el "mundo real".

Respeta tus puntos de vista y te tratarán bien.

¿Cuáles son las Diversas limitaciones de las vistas en SQL Server?

Top 11 Limitaciones de vistas

• Las vistas no soportan COUNT (); sin embargo, puede soportar COUNT_BIG ()
• La cláusula ORDER BY no funciona a la vista
• Las consultas regulares o los Procedimientos Almacenados nos dan flexibilidad cuando necesitamos otra columna; podemos agregar una columna a las consultas regulares de inmediato. Si queremos hacer lo mismo con las vistas, entonces tendremos que modificarlas primero
• Índice creado a la vista no utilizado a menudo
• Una vez que se crea la vista y si la tabla básica tiene alguna columna añadida o eliminada, generalmente no se refleja en la vista hasta que se actualiza
• La operación de UNIÓN no está permitida en la Vista indexada
• No podemos crear un Índice en una vista anidada situación significa que no podemos crear un índice en una vista que se construye desde otra vista.
• No se permite la UNIÓN AUTOMÁTICA en la Vista Indexada
• No se permite la Unión Externa en Indexado Vistas
• No Se permiten Consultas Cruzadas de Bases de Datos en la Vista Indexada

Source SQL MVP Pinal Dave

Http://blog.sqlauthority.com/2010/10/03/sql-server-the-limitations-of-the-views-eleven-and-more/

Cuando comencé, siempre pensé que las vistas agregaban sobrecarga de rendimiento, sin embargo, la experiencia pinta una historia diferente (el mecanismo de vista en sí tiene una sobrecarga insignificante).

Todo depende de cuál sea la consulta subyacente. Echa un vistazo a las vistas indexadas aquí o aquí , en última instancia, debe probar el rendimiento de ambas maneras para obtener un perfil de rendimiento claro

Mi mayor 'queja' es que ORDER BY no funciona en una vista. Si bien tiene sentido, es un caso que puede saltar y morder si no se espera. Debido a esto he tenido que cambiar lejos de usar vistas a SPROCS (que tienen más que suficientes problemas propios) en unos pocos casos en los que no pude especificar un ORDEN más tarde. (Me gustaría que hubiera una construcción con "VISTA FINAL" possibly por ejemplo, posiblemente incluir orden por -- semántica).

Http://blog.sqlauthority.com/2010/10/03/sql-server-the-limitations-of-the-views-eleven-and-more/ (La limitación # 1 es sobre el ORDEN POR: -)

Lo siguiente es un hack SQL que permite hacer referencia a un order by en una vista:

create view toto1 as 
select top 99.9999 percent F1
from Db1.dbo.T1 as a 
order by 1

Pero mi preferencia es usar Row_Number:

create view toto2 as 
select *,  ROW_NUMBER() over (order by [F1]) as RowN from ( 
select f1
from Db1.dbo.T1) as a