Estoy leyendo la Biblia de SQL Server 2008 y estoy cubriendo la sección de vistas. Pero el autor realmente no explica el propósito de vistas. ¿Cuál es un buen uso para las vistas? ¿Debo usarlos en mi sitio web y cuáles son los beneficios de ellos?¿Cuál es una buena razón para usar vistas de SQL?
Otro uso que ninguna de las respuestas anteriores parece haber mencionado es una implementación más sencilla de los cambios en la estructura de la tabla.
Digamos que desea retirar una tabla (T_OLD) que contiene datos para usuarios activos, y en su lugar usar una nueva tabla con datos similares (llamada T_NEW) pero con datos para usuarios activos e inactivos, con una columna adicional "activo".
Si su sistema (s) tiene consultas tropecientos que hacen SELECT whatever FROM T_OLD WHERE whatever, usted tiene dos opciones para la puesta en marcha:
1) Cold Turkey - Cambiar la base de datos, y al mismo tiempo, el cambio, la prueba y liberar numerosos fragmentos de código que contenían dicha consulta. MUY difícil de hacer (o incluso coordinar), muy arriesgado. Malo.
2) Gradual - cambiar la DB mediante la creación de T_new, dejando caer T_OLD y en lugar de la creación de un llamado T_OLD VISTA que imita la tabla T_OLD 100% (por ejemplo la consulta vista es SELECT all_fields_except_active FROM T_NEW WHERE active=1).
Eso le permitiría evitar la publicación de CUALQUIER código que actualmente seleccione de T_OLD, y hacer los cambios para migrar el código de T_OLD a T_NEW en el ocio.
Este es un ejemplo simple, hay otros mucho más involucrados.
P.S. Por otro lado, probablemente debería haber tenido una API de procedimiento almacenado en lugar de consultas directas de T_OLD, pero no siempre es así.
Las VISTAS se pueden utilizar como secciones reutilizables de SELECT/CODE, que pueden incluirse en otras selects/queries para unirse, y usar varios filtros diferentes, sin tener que volver a crear todo el SELECT cada vez.
Esto también coloca la lógica en una sola ubicación, para que no tenga que cambiarla por todo el código base.
Tenga una mirada en
Choice Between Stored Procedures, Functions, Views, Triggers, Inline SQL
La principal belleza de una opinión es que se puede utilizar como una mesa en la mayoría de situaciones, pero a diferencia de una mesa, se puede encapsular muy cálculos complejos y combinaciones comúnmente utilizadas. También puede usar casi cualquier objeto en el db , excepto por los procedimientos almacenados. Vistas son más útiles cuando se necesita siempre para unirse a la misma serie de mesas decir una Orden con un detalle de la orden para obtener campos de cálculo de resumen etc.
(Copiado de la first tutorial that came up in a Google search, pero tiene todas las los beneficios que habrían introducido manualmente yo)
Vistas de los siguientes beneficios:.
- Seguridad - Vistas se pueden hacer acce es posible para los usuarios, mientras que las tablas subyacentes no son accesibles directamente. Esto le permite al DBA brindar a los usuarios solo los datos que necesitan, mientras protege otros datos en la misma tabla.
- Simplicidad: las vistas se pueden usar para ocultar y reutilizar consultas complejas.
- Simplicación o aclaración del nombre de la columna: las vistas se pueden usar para proporcionar alias en los nombres de las columnas para que sean más memorables y/o significativas.
- Stepping Stone: las vistas pueden proporcionar un escalón en una consulta de "niveles múltiples". Por ejemplo, podría crear una vista de una consulta que contara el número de ventas que cada vendedor había hecho. A continuación, puede consultar esa vista para agrupar a los vendedores por el número de ventas que han realizado.
Porque me gusta su respuesta y no veo mucho sentido agregar otra, ¿puedo sugerir dos adiciones a su lista? Las vistas indizadas pueden aumentar el rendimiento. Ejecutar actualizaciones contra vistas en lugar de dirigirlas a tablas puede dar mayor seguridad de que no actualizará incorrectamente esa tabla de producción de claves :) –
Un punto más en su lista, a la mayoría de los DBA les gustaría usar la vista porque pueden sintonizar una vista y principalmente (no siempre) todas las consultas que utilizan esa vista se ajustarán. –
Esta es la respuesta del 99% en mi libro. –
Las vistas se permitirá combinar datos de varias tablas diferentes y darle formato (combinar campos, da nombres de los campos más significativos, etc.) para que sea más fácil para los usuarios finales. Son una abstracción del modelo de base de datos. También se pueden usar para dar acceso a los usuarios a los datos de la tabla sin darles acceso directo a la tabla.
Algunas de las razones de Wikipedia:
Vistas pueden proporcionar ventajas sobre tablas:
una pequeña lista de motivos comunes/usos:
ellos utilizan a Chan ge el formato o 'apariencia' de datos (es decir usted puede unirse a un nombre y apellido juntos)
realizar cálculos u otras operaciones de búsqueda en los datos
Desnormalizar datos (extraer datos de varias mesas para un mismo sitio)
Aquí hay un uso muy común del uso de vistas para restringir una entidad según algunos criterios.
Tabla: USUARIOS contiene todos los usuarios
Vista: ACTIVE_USERS contiene todos los usuarios excepto los que están en suspensión, prohibido, en espera de ser activado y que no cumplan con los criterios que usted puede elegir para definir en el futuro como parte del activo requisitos. Esto hace que no sea necesario eliminar las filas de la tabla USERS si no lo hace porque ACTIVE_USERS siempre puede ocultar las filas no deseadas.
De esta manera, puede usar la tabla en sus páginas de administración de usuarios, pero el resto de la aplicación puede usar ACTIVE_USERS, ya que pueden ser los únicos usuarios que deberían poder ejecutar procesos y acceder/modificar datos.
Una vista es una capa de abstracción, y hace lo que hace cualquier capa de abstracción, incluso encapsulando el esquema de base de datos y protegiéndote de las consecuencias de cambiar los detalles de implementación interna.
Es una interfaz.
Bonita perspectiva. – David
Siempre que no acumules vistas en las vistas para una mayor abstracción. – HLGEM
Creo que efectivamente he rechazado cualquier tipo de abstracción de varios niveles en las bases de datos relacionales. Y tampoco llamo a procedimientos almacenados de procedimientos almacenados. :) – dkretz
¡Las vistas son malas! Evítelos si es posible y utilícelos solo por el motivo mencionado por DVK: migración temporal de datos.
Debe comprender que en una base de datos con 100 tablas es difícil recordar el propósito de cada tabla. Ahora, si agrega aquí otras 300 vistas, se convertirá en un completo desastre. Que los "amantes de la vista" tienden a usar vistas anidadas y luego usan las vistas anidadas en los procedimientos almacenados. ¡Personalmente trabajo ahora con una base de datos donde hay Vistas anidadas en profundidad 4 veces! Para entender una lógica simplista de un procedimiento almacenado, primero tengo que pasar por todas las vistas.
-1 Las vistas son buenas. Ellos * pueden * volverse malvados si los usan de manera inapropiada, pero eso es cierto para cualquier cosa. – NullUserException
Las vistas pueden ser malas si se usan mal. Las personas que los usan con mayor frecuencia parecen ser los que los utilizan para abstraer cosas y luego hacer lo que usted dice, llamar vistas que llaman vistas que llaman vistas hasta el punto donde es posible que tenga que materializar 10 millones de reconexiones antes de devolver un resultado conjunto de 3. Vistas directamente llamadas tablas pueden ser muy útiles. – HLGEM
@HGLEM ¿hay alguna forma de restringir las llamadas de vista desde otras vistas? –
No siempre es cierto que no puede actualizar la tabla subyacente de una vista.
Por ejemplo, tratar
crear vista theyshallnotpass como seleccionar * de
y tener un ir en una actualización para una sorpresa desagradable ...
(MSSQL)
Aquí están algunas de las muchas razones para usar view en lugar de table directamente
guau ... esa es una muy buena razón – Luke101
¡EXCELENTE punto! – David
No conocía el término "API de procedimiento almacenado" y pros/contras asociados y encontré este artículo útil: http://www.codinghorror.com/blog/2005/05/stored-procedures-vs-ad-hoc-sql .html –