sql - varias - ¿Por qué creas una vista en una base de datos?

ejemplos de vistas en base de datos (24)

¿Cuándo y por qué alguien decide que necesita crear una Vista en su base de datos? ¿Por qué no simplemente ejecutar un procedimiento almacenado normal o seleccionar?

Aquí hay dos razones comunes:

Puedes usarlo por seguridad. No otorgue permisos en la tabla principal y cree vistas que limiten el acceso a la columna o fila y otorgue permisos a los usuarios para ver la vista.

Puedes usarlo por conveniencia. Une algunas tablas que usas todo el tiempo en la vista. Esto puede hacer que las consultas sean consistentes y más fáciles.

Aquí se explica cómo usar una Vista junto con los permisos para limitar las columnas que un usuario puede actualizar en la tabla.

/* This creates the view, limiting user to only 2 columns from MyTestTable */ CREATE VIEW dbo.myTESTview WITH SCHEMABINDING AS SELECT ID, Quantity FROM dbo.MyTestTable; /* This uses the view to execute an update on the table MyTestTable */ UPDATE dbo.myTESTview SET Quantity = 7 WHERE ID = 1

Creamos una vista para limitar o restringir el acceso a todas las filas / columnas de una tabla. Si el propietario desea que solo se deban compartir filas o columnas específicas o limitadas, creará una vista con esas columnas.

Creo que el primero. Para ocultar la complejidad de la consulta. Es muy apropiado para las vistas. Cómo normalizar los aumentos de las tablas de la base de datos. Ahora, para obtener datos es muy difícil cuando aumenta el número de tablas. Por lo tanto, la mejor forma de manejar es seguir las vistas. Si me equivoco, corríjame.

Cuando quiero ver una instantánea de una (s) tabla (s) y / o vista (de una manera de solo lectura)

En general, utilizo vistas para facilitarle la vida, obtengo detalles extendidos de alguna entidad que se almacena en varias tablas (elimine muchas combinaciones en el código para mejorar la legibilidad) y, a veces, comparta datos en varias bases de datos o incluso para facilitar la lectura de las inserciones.

Entre otras cosas, puede ser utilizado para la seguridad. Si tiene una tabla de "clientes", es posible que desee que todos sus vendedores tengan acceso a los campos de nombre, dirección, código postal, etc., pero no a credit_card_number. Puede crear una vista que solo incluya las columnas a las que necesitan acceso y luego otorgarles acceso en la vista.

Esto no responde exactamente a su pregunta, pero pensé que valdría la pena mencionar las Vistas materializadas . Mi experiencia es principalmente con Oracle pero supuestamente SQL-Server es bastante similar.

Utilizamos algo similar en nuestra arquitectura para abordar los problemas de rendimiento XML. Nuestros sistemas están diseñados con una gran cantidad de datos almacenados como XML en una fila y es posible que las aplicaciones necesiten consultar valores particulares dentro de ellos. El manejo de muchos XMLTypes y la ejecución de XPaths en un gran número de filas tiene un gran impacto en el rendimiento, por lo que usamos una forma de vistas materializadas para extraer los nodos XML deseados en una tabla relacional en cualquier momento que cambie la tabla base. Esto proporciona efectivamente una instantánea física de la consulta en un punto en el tiempo en lugar de vistas estándar que ejecutarían su consulta a pedido.

Estoy creando xxx que mapea todas las relaciones entre una tabla principal (como la tabla Productos) y tablas de referencia (como ProductType o ProductDescriptionByLanguage). Esto creará una vista que me permitirá recuperar un producto y todos los detalles traducidos de sus claves externas a su descripción. Entonces puedo usar un ORM para crear objetos para construir cuadrículas, cuadros combinados, etc.

Hay más de una razón para hacer esto. Algunas veces hace que las consultas de unión comunes sean fáciles, ya que uno solo puede consultar el nombre de una tabla en lugar de hacer todas las combinaciones.

Otra razón es limitar los datos a diferentes usuarios. Así, por ejemplo:

Table1: Colums - USER_ID; USERNAME; SSN

Los usuarios administradores pueden tener privilegios en la tabla real, pero los usuarios a los que no desea tener acceso para decir el SSN, crean una vista como

CREATE VIEW USERNAMES AS SELECT user_id, username FROM Table1;

Entonces dales privs para acceder a la vista y no a la tabla.

Las vistas pueden ser una bendición cuando se informa sobre bases de datos heredadas. En particular, puede usar nombres de tablas sensuales en lugar de nombres de 5 letras crípticas (donde 2 de ellas son un prefijo común), o nombres de columnas llenas de abreviaturas que estoy seguro que tenían sentido en ese momento.

Las vistas también dividen configuraciones y tablas muy complejas en partes manejables que son fáciles de consultar. En nuestra base de datos, nuestro sistema completo de gestión de tablas se divide en vistas desde una tabla grande.

Me gusta usar vistas sobre procedimientos almacenados cuando solo estoy ejecutando una consulta. Las vistas también pueden simplificar la seguridad, se pueden usar para facilitar inserciones / actualizaciones en varias tablas, y se pueden usar para hacer instantáneas / materializar datos (ejecutar una consulta de larga duración y mantener los resultados en caché).

He utilizado vistas materializadas para ejecutar consultas de larga duración que no es necesario que se mantengan precisas en tiempo real.

Piense en ello como refactorizando el esquema de su base de datos.

Por lo general, creo vistas para des-normalizar y / o agregar datos que se usan con frecuencia para informar.

EDITAR

A modo de elaboración, si tuviera una base de datos en la que algunas de las entidades fueran persona, empresa, rol, tipo de propietario, orden, detalle de pedido, dirección y teléfono, donde la tabla de personas almacenaba tanto empleados como contactos y la dirección y las mesas de teléfono almacenaron números de teléfono tanto para personas como para empresas, y el equipo de desarrollo tuvo la tarea de generar informes (o hacer que los datos de los informes sean accesibles para los no desarrolladores), como ventas por empleado, ventas por cliente o ventas por región, ventas por mes Clientes por estado, etc. Crearía un conjunto de vistas que des-normalizaba las relaciones entre las entidades de la base de datos para que estuviera disponible una vista más integrada (sin intenciones de palabra) de las entidades del mundo real. Algunos de los beneficios podrían incluir:

Reducir la redundancia en las consultas de escritura.
Establecimiento de una norma para entidades vinculadas.
Brindar oportunidades para evaluar y maximizar el rendimiento para cálculos complejos y combinaciones (por ejemplo, indexación en vistas de Schemabound en MSSQL)
Hacer que los datos sean más accesibles e intuitivos para los miembros del equipo y los no desarrolladores.

Puede funcionar como un buen "intermediario" entre su ORM y sus tablas.

Ejemplo:

Teníamos una tabla de Personas que necesitábamos para cambiar la estructura, por lo que la columna SomeColumn se movería a otra tabla y tendría una relación de uno a muchos.

Sin embargo, la mayoría del sistema, con respecto a la Persona, todavía usaba SomeColumn como una sola cosa, no muchas cosas. Usamos una vista para juntar todas las Columnas de algunos y ponerla en la vista, que funcionó muy bien.

Esto funcionó porque la capa de datos había cambiado, pero los requisitos del negocio no habían cambiado fundamentalmente, por lo que los objetos de negocio no tenían que cambiar. Si los objetos de negocio tuvieran que cambiar, no creo que esta hubiera sido una solución viable, pero las vistas definitivamente funcionan como un buen punto medio.

Solo tengo 10 o más vistas en mis bases de datos de producción. Yo uso varias para las columnas que uso todo el tiempo. Uno de los conjuntos que utilizo proviene de 7 tablas, algunos con combinaciones externas y, en lugar de volver a escribir, constantemente solo tengo que llamar a esa vista en una selección y hacer una o dos combinaciones. Para mí es solo un ahorro de tiempo.

Una cosa curiosa acerca de las vistas es que Microsoft Access las ve como tablas: cuando adjunta un front-end de Microsoft Access a una base de datos SQL mediante ODBC, puede ver las tablas y vistas en la lista de tablas disponibles. Por lo tanto, si está preparando informes complicados en MS Access, puede permitir que el servidor SQL realice la unión y la consulta, y simplifique enormemente su vida. Lo mismo vale para preparar una consulta en MS Excel.

Una vista es una encapsulación de una consulta. Las consultas que se convierten en vistas tienden a ser complicadas y, por lo tanto, guardarlas como una vista para reutilizar puede ser ventajoso.

Una vista proporciona varios beneficios.

1. Las vistas pueden ocultar la complejidad.

Si tiene una consulta que requiere unir varias tablas, o tiene una lógica o cálculos complejos, puede codificar toda esa lógica en una vista, luego seleccionar desde la vista como si fuera una tabla.

2. Las vistas pueden ser usadas como un mecanismo de seguridad.

Una vista puede seleccionar ciertas columnas y / o filas de una tabla, y los permisos establecidos en la vista en lugar de las tablas subyacentes. Esto permite que aparezcan solo los datos que un usuario necesita ver.

3. Las vistas pueden simplificar el soporte de código heredado

Si necesita refactorizar una tabla que rompería una gran cantidad de código, puede reemplazar la tabla con una vista del mismo nombre. La vista proporciona el mismo esquema exacto que la tabla original, mientras que el esquema real ha cambiado. Esto evita que el código heredado que hace referencia a la tabla se rompa, lo que le permite cambiar el código heredado a su gusto.

Estos son solo algunos de los muchos ejemplos de cómo las vistas pueden ser útiles.

Varias razones: si tiene uniones complicadas, a veces es mejor tener una vista para que cualquier acceso siempre tenga las uniones correctas y los desarrolladores no tengan que recordar todas las tablas que puedan necesitar. Por lo general, esto puede ser para una aplicación financiera en la que sería extremadamente importante que todos los informes financieros se basen en el mismo conjunto de datos.

Si tiene usuarios a los que desea limitar los registros que pueden ver, puede usar una vista, darles acceso solo a la vista, no a las tablas subyacentes y luego consultar la vista

Los informes de Crystal parecen preferir usar vistas para procs almacenados, por lo que las personas que escriben muchos informes tienden a usar muchas vistas

Las vistas también son muy útiles al refactorizar bases de datos. A menudo puede ocultar el cambio para que el código anterior no lo vea creando una vista. Lea en las bases de datos de refactorización para ver cómo funciona esto, ya que es una forma muy poderosa de refactorizar.

Veo un procedimiento almacenado más como un método al que puedo llamar contra mis datos, mientras que para mí, una vista proporciona un mecanismo para crear una versión sintética de los datos básicos contra los cuales se pueden crear consultas o procedimientos almacenados. Crearé una vista cuando la simplificación o la agregación tenga sentido. Escribiré un procedimiento almacenado cuando quiera proporcionar un servicio muy específico.

Para centrarse en las vistas de datos específicos, los usuarios pueden centrarse en los datos específicos que les interesan y en las tareas específicas de las que son responsables. Los datos innecesarios se pueden dejar fuera de la vista. Esto también aumenta la seguridad de los datos porque los usuarios solo pueden ver los datos que se definen en la vista y no los datos en la tabla subyacente. Para obtener más información sobre el uso de vistas con fines de seguridad, consulte Uso de vistas como mecanismos de seguridad.

Simplificar las vistas de manipulación de datos puede simplificar la forma en que los usuarios manipulan los datos. Puede definir uniones de uso frecuente, proyecciones, consultas UNION y consultas SELECT como vistas para que los usuarios no tengan que especificar todas las condiciones y calificaciones cada vez que se realice una operación adicional en esos datos. Por ejemplo, una consulta compleja que se usa con fines de informes y realiza subconsultas, combinaciones externas y agregación para recuperar datos de un grupo de tablas se puede crear como una vista. La vista simplifica el acceso a los datos porque la consulta subyacente no tiene que escribirse o enviarse cada vez que se genera el informe; la vista se consulta en su lugar. Para más información sobre la manipulación de datos.

También puede crear funciones en línea definidas por el usuario que operan lógicamente como vistas parametrizadas, o vistas que tienen parámetros en las condiciones de búsqueda de la cláusula WHERE. Para obtener más información, vea Funciones en línea definidas por el usuario.

Para personalizar las vistas de datos, los diferentes usuarios pueden ver los datos de diferentes maneras, incluso cuando utilizan los mismos datos al mismo tiempo. Esto es particularmente ventajoso cuando los usuarios con diferentes intereses y niveles de habilidad comparten la misma base de datos. Por ejemplo, se puede crear una vista que recupera solo los datos de los clientes con los que trata un administrador de cuentas. La vista puede determinar qué datos recuperar según el ID de inicio de sesión del administrador de cuentas que usa la vista.

Para exportar e importar vistas de datos puede utilizarse para exportar datos a otras aplicaciones. Por ejemplo, es posible que desee utilizar las tiendas y las tablas de ventas en la base de datos de pubs para analizar los datos de ventas utilizando Microsoft® Excel. Para hacer esto, puede crear una vista basada en las tiendas y las tablas de ventas. Luego puede usar la utilidad bcp para exportar los datos definidos por la vista. Los datos también se pueden importar a ciertas vistas desde archivos de datos usando la utilidad bcp o la declaración BULK INSERT, siempre que las filas se puedan insertar en la vista usando la declaración INSERT. Para obtener más información sobre las restricciones para copiar datos en vistas, consulte INSERTAR. Para obtener más información sobre el uso de la utilidad bcp y la declaración BULK INSERT para copiar datos desde y hacia una vista, consulte Copiar en o desde una vista.

Para combinar datos particionados El operador de conjuntos Transact-SQL UNION se puede usar dentro de una vista para combinar los resultados de dos o más consultas de tablas separadas en un único conjunto de resultados. Esto le aparece al usuario como una tabla única llamada vista particionada. Por ejemplo, si una tabla contiene datos de ventas de Washington y otra tabla contiene datos de ventas de California, se podría crear una vista desde la UNION de esas tablas. La vista representa los datos de ventas para ambas regiones. Para usar vistas particionadas, crea varias tablas idénticas, especificando una restricción para determinar el rango de datos que se pueden agregar a cada tabla. La vista luego se crea utilizando estas tablas base. Cuando se consulta la vista, SQL Server determina automáticamente qué tablas se ven afectadas por la consulta y hace referencia solo a esas tablas. Por ejemplo, si una consulta especifica que solo se requieren datos de ventas para el estado de Washington, SQL Server lee solo la tabla que contiene los datos de ventas de Washington; no se accede a otras mesas.

Las vistas particionadas pueden basarse en datos de múltiples fuentes heterogéneas, como servidores remotos, no solo tablas en la misma base de datos. Por ejemplo, para combinar datos de diferentes servidores remotos, cada uno de los cuales almacena datos para una región diferente de su organización, puede crear consultas distribuidas que recuperan datos de cada fuente de datos y luego crear una vista basada en esas consultas distribuidas. Cualquier consulta lee solo datos de las tablas en los servidores remotos que contienen los datos solicitados por la consulta; No se accede a los otros servidores a los que hacen referencia las consultas distribuidas en la vista.

Cuando particiona los datos en varias tablas o múltiples servidores, las consultas que acceden a solo una fracción de los datos pueden ejecutarse más rápido porque hay menos datos para analizar. Si las tablas están ubicadas en servidores diferentes, o en una computadora con múltiples procesadores, cada tabla involucrada en la consulta también se puede escanear en paralelo, mejorando así el rendimiento de la consulta. Además, las tareas de mantenimiento, como la reconstrucción de índices o la copia de seguridad de una tabla, pueden ejecutarse más rápidamente. Al utilizar una vista particionada, los datos siguen apareciendo como una sola tabla y se pueden consultar como tales sin tener que hacer referencia manualmente a la tabla subyacente correcta.

Las vistas particionadas son actualizables si se cumple alguna de estas condiciones: un desencadenador INSTEAD OF se define en la vista con lógica para admitir las instrucciones INSERT, UPDATE y DELETE.

Tanto la vista como las instrucciones INSERT, UPDATE y DELETE siguen las reglas definidas para las vistas particionables actualizables. Para obtener más información, consulte Crear una vista con particiones.

https://technet.microsoft.com/en-us/library/aa214282(v=sql.80).aspx#sql:join

La principal ventaja de una vista sobre un procedimiento almacenado es que puede usar una vista al igual que una tabla. Es decir, se puede hacer referencia a una vista directamente en la cláusula FROM de una consulta. Por ejemplo, SELECT * FROM dbo.name_of_view .

En casi cualquier otra forma, los procedimientos almacenados son más poderosos. Puede pasar parámetros, incluidos parámetros que le permiten devolver efectivamente varios valores a la vez, puede realizar operaciones de SELECT , INSERT , UPDATE , DELETE , etc. etc.

Si desea que una vista pueda realizar consultas desde la cláusula FROM , pero también desea poder pasar parámetros, también hay una manera de hacerlo. Se llama una función de tabla de valores.

Aquí hay un artículo bastante útil sobre el tema:

http://databases.aspfaq.com/database/should-i-use-a-view-a-stored-procedure-or-a-user-defined-function.html

EDIT: Por cierto, este tipo de pregunta plantea, ¿qué ventaja tiene una vista sobre una función de valor de tabla? No tengo una respuesta realmente buena a eso, pero observo que la sintaxis de T-SQL para crear una vista es más simple que para una función con valores de tabla, y los usuarios de su base de datos pueden estar más familiarizados con las vistas.