Esta pregunta es sobre vistas de la base de datos, no vistas materializadas.Cuándo usar las vistas de la base de datos y cuándo no?
Pros:
Contras:
¿Qué más?
Pros: Le permite cambiar las estructuras de datos subyacentes sin afectar a las consultas aplicaciones están usando (siempre y cuando su punto de vista puede ocultar las estructuras de datos)
Las vistas son bastante impresionantes cuando usted no confía en su totalidad la Parte enviando consultas a su base de datos. Un buen ejemplo podría ser crear una vista en tablas para un contratista para que todo lo que puedan ver sean las filas pertenecientes a su proyecto.
Seguridad. Otorgue acceso en una vista a los usuarios que deberían poder ver las columnas devueltas desde él.
Solía usarlos todo el tiempo, ahora raramente. Sin embargo, hago todo mi acceso a los datos a través de los procedimientos almacenados, por lo que la utilidad de una vista es algo menor ya que el SP puede ocultar la complejidad de la unión cuando sea necesario.
Todavía consideraría usar una vista si tuviera una combinación particularmente complicada de muchas tablas, de la cual necesitaba construir varios SP además, pero para ser honesto, no puedo pensar en ninguna que tenga. en producción en este momento.
El otro escenario en el que utilizaría uno sería cuando mis usuarios tienen acceso a la base de datos para generar sus propios informes, y quería ocultar la complejidad subyacente para ellos.
Ahora que SQL Server tiene common table expressions me encuentro creando menos vistas. Cuando creo una vista, generalmente es para una jerarquía normalizada que puede usarse en muchas consultas, no en algo que reemplace una consulta.
Por ejemplo Región, Mercado y Ciudad pueden ser tres tablas normalizadas (copo de nieve). El 90% de mis consultas necesitan esta información, así que crearé una vista. La vista nunca reemplaza una sola consulta, pero hace que todas las demás consultas sean simples y SECAS.
Aunque las vistas pueden ocultar la complejidad y las combinaciones múltiples, esta es la complejidad que habría estado en el SP de todos modos.
Si el SP podría haberse optimizado, la vista debería optimizarse, lo que aumentaría el rendimiento de todos los SP que alcanzaran esa vista.
Las vistas son increíblemente potentes y útiles por una razón que destaca sobre todas las otras muy buenas razones. Reducen la duplicación de código. Es decir, en la mayoría de los casos, el resultado final. Si una consulta se utilizará en tres o más lugares, una vista simplificará drásticamente sus cambios si el esquema o los parámetros de consulta cambian.
Una vez tuve que editar 22 procedimientos almacenados para cambiar alguna lógica de consulta. Si la arquitectura original hubiera utilizado vistas, entonces habría tenido solo tres cambios.
He tenido que usar vistas varias veces para hacer combinaciones extrañas y agrupar por alias.
Por combinaciones extrañas, me refiero a seleccionar una lista de fechas distintas y luego unirlas de nuevo a la tabla de donde provienen para obtener entradas nulas para días vacíos. No pude encontrar otra forma de hacerlo.
En cuanto a la agrupación por alias, parece depender de la complejidad de la fórmula dentro del alias. Si el alias no hacía referencia a columnas reales, o columnas que ya estaban siendo agrupadas, todo estaba bien, pero los alias en las columnas que no estaban incluidas en la agrupación arrojaban errores.
Me parece recordar haber leído o escuchado en alguna parte de mis días universitarios que seleccionar de una vista era más rápido que seleccionar de un grupo de tablas unidas, pero no sé si eso es cierto.
Una última ventaja de utilizar una vista: tablas dinámicas en Excel. No creo que haya una forma de unir tablas, o al menos no en la interfaz del asistente. Es posible hacer uniones en Microsoft Query, pero aún no lo he intentado porque ahora se me acaba de ocurrir la idea.
[aquí] [1] es otra respuesta Creo que va a ser útil [1]: http://stackoverflow.com/questions/1278521/why-do-you-create- a-view-in-a-database – saman