database - optimizacion - ¿Las vistas de bases de datos afectan el rendimiento de las consultas?
optimizar consultas sql oracle (7)
Aunque una determinada consulta que se ejecuta dentro de una vista y la misma consulta que se ejecuta fuera de la vista deben funcionar de manera equivalente, las cosas se complican mucho más rápido cuando necesita unir dos vistas. Puede terminar fácilmente trayendo tablas que no necesita en la consulta, o trayendo tablas de forma redundante. El optimizador de la base de datos puede tener más problemas para crear un buen plan de ejecución de consultas. Por lo tanto, aunque las vistas pueden ser muy buenas en términos de permitir una seguridad de grano más fino y similares, no son necesariamente buenas para la modularidad.
¿Las vistas de la base de datos son solo un medio para simplificar el acceso a los datos o proporcionan beneficios de rendimiento al acceder a las vistas en lugar de simplemente ejecutar la consulta en la que se basa la vista? Sospecho que las vistas son funcionalmente equivalentes a solo agregar la consulta de vista almacenada a cada consulta en la vista de datos, ¿es correcto o hay otros detalles y / o optimizaciones que suceden?
Depende del RDBMS, pero generalmente no hay optimización, y es solo una forma conveniente de simplificar las consultas. Algunos sistemas de bases de datos usan "vistas materializadas", sin embargo, que usan un mecanismo de almacenamiento en caché.
En términos generales, las vistas deben funcionar de manera equivalente a una consulta escrita directamente en las tablas subyacentes.
Pero: puede haber casos extremos, y le conviene probar su código. Todos los sistemas RDBMS modernos tienen herramientas que le permitirán ver los planes de consulta y supervisar la ejecución. No tome mi palabra (ni la de nadie) por ella, cuando pueda tener los datos definitivos a su alcance.
Por lo general, una vista es solo una forma de crear una abreviatura común para definir conjuntos de resultados que necesita con frecuencia.
Sin embargo, hay un inconveniente. La tentación es agregar en cada columna que crees que necesitarás en algún momento cuando desees utilizar la vista. Entonces YAGNI es violado. No solo las columnas, sino que a veces se unen las uniones externas adicionales en "por las dudas". Así que cubrir los índices puede que ya no cubran, y el plan de consulta puede aumentar en complejidad (y disminuir la eficiencia).
YAGNI es un concepto crítico en el diseño de SQL.
Siempre consideré que Views era como un procedimiento almacenado de solo lectura. Proporciona a la base de datos la mayor cantidad de información posible por adelantado para que pueda precompilar lo mejor que pueda.
También puede indexar las vistas, lo que le permite acceder a una vista optimizada de los datos que está buscando para el tipo de consulta que está ejecutando.
Sé que es un viejo tema. La discusión es buena, pero quiero echar un pensamiento más. El rendimiento también depende de lo que está utilizando para extraer datos. Por ejemplo, si tiene acceso directo a algo como Microsoft Access, definitivamente puede obtener rendimiento para algunas consultas complejas mediante el uso de una vista. Esto se debe a que Access no siempre extrae del servidor SQL lo que quisiéramos, en algunos casos atraería tablas enteras e intentaría procesar localmente desde allí. No es así si usa una vista.
Sí, en todos los RDBMS modernos (MSSQL después de 2005, etc.) los planes de consulta de la vista se almacenan en caché, lo que elimina la sobrecarga de la planificación de la consulta y acelera el rendimiento en el mismo SQL ejecutado en línea. Anteriormente a esto (y también se aplica a SQL parametrizado / Declaraciones preparadas), las personas pensaban correctamente que los procedimientos almacenados tenían un mejor rendimiento.
Muchos aún se aferran a esto hoy por lo que es un mito moderno DB. Desde que Views / PS obtuvieron la planificación de consulta en caché de los SP, han sido bastante parejos.