¿Cuáles son las desventajas de usar SqlServer Views?

Question

¿Cuáles son las desventajas de usar SqlServer Views?

Creo vistas con frecuencia para mostrar mis datos en una forma desnormalizada.

Me resulta mucho más fácil y, por lo tanto, más rápido, menos propenso a errores y más documentado, consultar una de estas combinaciones en lugar de generar consultas complejas con combinaciones complicadas entre muchas tablas. Especialmente cuando estoy analizando los mismos datos (muchos campos iguales, la misma mesa se une) desde diferentes ángulos.

¿Pero hay un costo para crear y usar estas vistas?

¿Estoy ralentizando (o acelerando?) El procesamiento de consultas?

Answer 1

Cuando se trata de Vistas, hay ventajas y desventajas.

Ventajas:

1. Son tablas virtuales y no almacenados en la base de datos como un objeto distinto. Todo lo que está almacenado es la declaración SELECT.
2. Se puede utilizar como una medida de seguridad restringiendo lo que el usuario puede ver.
3. Puede hacer que las consultas complejas de uso común sean más fáciles de leer al encapsularlas en una vista. Sin embargo, esta es una espada de doble filo: vea las desventajas # 3.

Desventajas:

1. que no tiene un plan de ejecución optimizado almacena en caché por lo que no será tan rápido como un procedimiento almacenado.
2. Dado que es básicamente una abstracción de un SELECT, es un poco más lento que hacer un SELECT puro.
3. Puede ocultar la complejidad y provocar problemas. (Conseguido: ORDEN POR no honrado).

Mi opinión personal es no utilizar las vistas, sino utilizar los procedimientos almacenados, ya que proporcionan la seguridad y el encapsulamiento de las vistas, pero también ofrecen un mejor rendimiento.

Answer 2

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

En SQL Server también puede create materialized or indexed views (desde SQL Server 2000), lo que aumenta un poco la velocidad.

Answer 3

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 las tablas subyacentes cambian con frecuencia (especialmente durante el desarrollo).

EDITAR: Una vez dicho esto, considero 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.

Answer 4

Cuando comencé, siempre pensé en agregar una sobrecarga de rendimiento adicional, sin embargo, la experiencia pinta una historia diferente (el mecanismo de visualización en sí tiene una sobrecarga insignificante).

Todo depende de cuál es la consulta subyacente. Echa un vistazo a las vistas indizadas o herehere, en última instancia, usted debe probar el rendimiento en ambos sentidos para obtener un perfil de rendimiento clara

Answer 5

Una desventaja de puntos de vista que me he encontrado es una inmersión en el rendimiento cuando su incorporación en las consultas distribuidas. Este artículo SQLMag discute, y aunque utilizo 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.

Answer 6

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

Para un proyecto particularmente grande y complejo diseñé un conjunto de vistas que debían ser utilizadas principalmente por diseñadores de informes para rellenar informes de cristal. Descubrí semanas más tarde que los desarrolladores menores habían empezado a usar estas vistas para buscar agregados y unir estas vistas ya de por sí grandes simplemente porque estaban allí y eran fáciles de consumir. (Hubo un fuerte elemento de diseño EAV en la base de datos.) Me enteré de esto después de que los desarrolladores principiantes comenzaron a preguntar por qué los informes aparentemente simples llevaban varios minutos en ejecutarse.

Answer 7

Las vistas pueden ser perjudiciales para el rendimiento cuando la vista contiene lógica, columnas, filas o tablas que no son finalmente utilizadas por su consulta final. No puedo decirle cuántas veces he visto cosas como:

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

(tanto el filtrado de todas las filas que se incluyeron en la vista desde la mesa InactiveCustomer), o

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

(SQL tiene que recuperar una gran cantidad de datos que después se desecha en un paso posterior. sus posibles esas otras columnas son caros para recuperar, al igual que a través de una búsqueda de marcador), o

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

(su probable que SQL podría tener se utiliza un índice más apropiado si las tablas se les preguntó directamente), o

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

(un montón de recursos de la CPU a través de la unión, y la innecesaria IO para la mesa de lecturas que se desecha después), o mi favorito:

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

(Lee 12 tablas cuando 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 elaborar un plan de consulta eficaz de todos modos. Pero en otros casos (especialmente los muy complejos), no puede. En cada una de las situaciones anteriores, la respuesta fue eliminar la vista y consultar en su lugar las tablas subyacentes.

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

Answer 8

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, tuve que cambiar desde el uso de vistas a SPROCS (que tienen problemas más que suficientes) en algunos casos donde no pude especificar un ORDER BY más tarde. (Desearía que hubiera una construcción con "VISTA FINAL", 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/ (Limitación # 1 está a punto ORDER BY :-)

Answer 9

¿Cuáles son diversas limitaciones de las Vistas en SQL Server?

Top 11 Limitaciones de Vistas

• Vistas no son compatibles con COUNT (); Sin embargo, puede apoyar COUNT_BIG ()
• cláusula ORDER BY no funciona en Vista
• consultas periódicas o procedimientos almacenados nos dan flexibilidad cuando necesitamos otra columna; podemos agregar una columna a consultas regulares de inmediato. Si queremos hacer lo mismo con Vistas, entonces tendremos que modificarlas primero
• Índice creado en la vista no se usa con frecuencia
• Una vez que se crea la vista y si la tabla básica tiene alguna columna añadida o eliminada, es no suele reflejarse en la vista hasta que se renueve
• UNIÓN La operación no está permitida en la vista Indexada
• No podemos crear un índice en una situación de vista anidada significa que no podemos crear un índice en una vista que está construida desde otra vista.
• autorrestricción No se permite en vista indizada
• combinación externa no se permite en vistas indizadas
• consultas a la base de la Cruz No se permite en vista indizada

Fuente SQL MVP Pinal de Dave

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

Answer 10

El siguiente es un hack SQL que permite hacer referencia a una orden 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 utilizar Row_Number:

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