¿Para qué sirven las vistas?

Solo estoy tratando de tener una idea general de para qué se utilizan las vistas en RDBMS. Es decir, sé qué es una vista y cómo hacerla. También sé para qué los he usado en el pasado.

Pero quiero asegurarme de tener un conocimiento profundo de para qué es útil una vista y para qué no debería ser útil una vista. Más específicamente:

1. ¿Para qué es útil una vista?
   • ¿Existe alguna situación en la que resulte tentador utilizar una vista cuando no debería utilizarla?
   • ¿Por qué usaría una vista en lugar de algo como una función con valores de tabla o viceversa?
   • ¿Existe alguna circunstancia en la que una vista pueda ser útil que no sea evidente a primera vista?

(Y para que conste, algunas de estas preguntas son intencionadamente ingenuas. Esto es en parte una verificación de conceptos).

1) ¿Para qué es útil una vista?

IOPO en un solo lugar

• Ya sea que considere los datos en sí o las consultas que hacen referencia a las tablas unidas, el uso de una vista evita redundancias innecesarias.

• Las vistas también proporcionan una capa de abstracción que evita el acceso directo a las tablas (y las esposas resultantes que hacen referencia a dependencias físicas). De hecho, creo que es una buena práctica ¹ ofrecer solo acceso abstracto a sus datos subyacentes (utilizando vistas y funciones con valores de tabla), incluidas vistas como ¹ Tengo que admitir que hay una buena cantidad de "Haz lo que digo, no lo que yo hacer "en ese consejo;)

CREATE VIEW AS
      SELECT * FROM tblData

2) ¿Existe alguna situación en la que resulte tentador utilizar una vista cuando no debería utilizarla?

El rendimiento en las uniones de vista solía ser una preocupación (por ejemplo, SQL 2000). No soy un experto, pero hace tiempo que no me preocupa. (Tampoco puedo pensar en dónde estoy usando actualmente combinaciones de vistas).

Otra situación en la que una vista podría ser excesiva es cuando la vista solo se referencia desde una ubicación de llamada y se podría usar una tabla derivada en su lugar. Al igual que un tipo anónimo es preferible a una clase en .NET si el tipo anónimo solo se usa / referencia una vez.

    • Consulte la descripción de la tabla derivada en http://msdn.microsoft.com/en-us/library/ms177634.aspx

3) ¿Por qué usaría una vista en lugar de algo como una función con valores de tabla o viceversa?

(Aparte de razones de rendimiento) Una función con valores de tabla es funcionalmente equivalente a una vista parametrizada. De hecho, un caso de uso común de una función con valores de tabla simple es simplemente agregar un filtro de cláusula WHERE a una vista ya existente en un solo objeto.

4) ¿Existe alguna circunstancia en la que una vista pueda ser útil que no sea evidente a primera vista?

No puedo pensar en ningún uso no aparente de la parte superior de mi cabeza. (Supongo que si pudiera, eso los haría evidentes;)

En cierto modo, una vista es como una interfaz. Puede cambiar la estructura de la tabla subyacente todo lo que desee, pero la vista proporciona una forma para que el código no tenga que cambiar.

Las vistas son una buena forma de proporcionar algo sencillo a los redactores de informes. Si los usuarios de su empresa desean acceder a los datos de algo como Crystal Reports, puede darles algunas vistas en su cuenta que simplifiquen los datos, tal vez incluso desnormalicen para ellos.

Las vistas se pueden utilizar para proporcionar seguridad (es decir, los usuarios pueden tener acceso a vistas que solo acceden a determinadas columnas de una tabla), las vistas pueden proporcionar seguridad adicional para actualizaciones, inserciones, etc. sp's) pero las vistas son más un aislamiento de la tabla real.

En cierto sentido, las vistas se desnormalizan. La desnormalización a veces es necesaria para proporcionar datos de una manera más significativa. Esto es lo que hacen muchas aplicaciones de todos modos mediante el modelado de dominios en sus objetos. Ayudan a presentar los datos de una manera que se asemeja más a la perspectiva de una empresa.

Además de lo que han dicho los demás, las vistas también pueden ser útiles para eliminar consultas SQL más completas de la aplicación.

Como ejemplo, en lugar de hacerlo en una aplicación:

sql = "seleccione a, b de la tabla1 unión seleccione a, b de la tabla2";

Podrías abstraer eso a una vista:

crear vista union_table1_table2_v como
seleccione a, b de la tabla1
unión
seleccione a, b de la tabla2

y en el código de la aplicación, simplemente tienes:

sql = "seleccione a, b de union_table1_table2_v";

Además, si las estructuras de datos alguna vez cambian, no tendrá que cambiar el código de la aplicación, volver a compilar y volver a implementar. simplemente cambiaría la vista en el archivo db.

Las vistas ocultan la complejidad de la base de datos. Son excelentes por muchas razones y son útiles en muchas situaciones, pero si tiene usuarios que pueden escribir sus propias consultas e informes, puede usarlos como salvaguarda para asegurarse de que no envíen mensajes mal diseñados. consultas con uniones cartesianas desagradables que derriban su servidor de base de datos.

El OP preguntó si había situaciones en las que podría ser tentador usar una vista, pero no es apropiado.

Lo que no desea utilizar una vista es un sustituto de combinaciones complejas. Es decir, no permita que su hábito de programación de procedimientos de dividir un problema en partes más pequeñas lo lleve a usar varias vistas unidas en lugar de una combinación más grande. Hacerlo matará la eficiencia del motor de la base de datos, ya que esencialmente está haciendo varias consultas separadas en lugar de una más grande.

Por ejemplo, digamos que tiene que unir las tablas A, B, C y D juntas. Puede tener la tentación de hacer una vista de las tablas A y B y una vista de C y D, y luego unir las dos vistas. Es mucho mejor unir A, B, C y D en una consulta.

Las vistas pueden centralizar o consolidar datos. Donde estoy, tenemos varias bases de datos diferentes en un par de servidores vinculados diferentes. Cada base de datos contiene datos para una aplicación diferente. Algunas de esas bases de datos contienen información que es relevante para varias aplicaciones diferentes. Lo que haremos en esas circunstancias es crear una vista en la base de datos de esa aplicación que simplemente extrae datos de la base de datos donde realmente se almacenan los datos, de modo que las consultas que escribimos no parezcan estar pasando por diferentes bases de datos.

Las respuestas hasta ahora son correctas: las vistas son buenas para brindar seguridad, desnormalización (aunque hay mucho dolor en ese camino si se hace mal), abstracción del modelo de datos, etc.

Además, las vistas se utilizan comúnmente para implementar la lógica empresarial (un usuario inactivo es un usuario que no ha iniciado sesión en los últimos 40 días, ese tipo de cosas).

Las vistas guardan muchas declaraciones JOIN complejas repetidas en sus scripts SQL. Puede encapsular algún JOIN complejo en alguna vista y llamarlo en su declaración SELECT cuando sea necesario. A veces, esto sería útil, sencillo y más fácil que escribir las declaraciones de combinación en cada consulta.

Una vista es simplemente una instrucción SELECT almacenada y con nombre. Piense en vistas como funciones de biblioteca.

Quería destacar el uso de vistas para informar. A menudo, existe un conflicto entre normalizar las tablas de la base de datos para acelerar el rendimiento, especialmente para editar e insertar datos (usos OLTP), y desnormalizar para reducir el número de uniones de tablas para consultas para informes y análisis (usos OLAP). Por necesidad, OLTP suele ganar, porque la entrada de datos debe tener un rendimiento óptimo. La creación de vistas, entonces, para un rendimiento óptimo de los informes, puede ayudar a satisfacer ambas clases de usuarios (entrada de datos y lectores de informes).

Recuerdo un SELECT muy largo que involucró a varios UNION. Cada UNION incluía una combinación a una tabla de precios que fue creada sobre la marcha por un SELECT que en sí mismo era bastante largo y difícil de entender. Creo que habría sido una buena idea tener una visión para crear la tabla de precios. Habría acortado el SELECT general aproximadamente a la mitad.

No sé si la base de datos evaluaría la vista una vez o una vez cada vez que se invocara. ¿Nadie sabe? Si es lo primero, el uso de una vista mejoraría el rendimiento.

Siempre que necesite [my_interface]! = [User_interface].

Ejemplo:

TABLA A:

• carné de identidad
• info

VER para la TABLA A:

• Información al cliente

esta es una forma en que puede ocultar la identificación del cliente y cambiar el nombre de la información a un nombre más detallado a la vez.

La vista utilizará el índice subyacente para la identificación de la clave principal, por lo que no verá una pérdida de rendimiento, solo una mejor abstracción de la consulta de selección.