vista - sql server ejemplo

Vistas de SQL Server, bendición o maldición? (12)

Al igual que todas las vistas de poder tienen su propio lado oscuro. Sin embargo, no se puede culpar a las vistas cuando alguien escribe un código mal ejecutado. Además, las vistas pueden limitar la exposición de algunas columnas y proporcionar seguridad adicional.

Una vez trabajé con un arquitecto que prohibió el uso de vistas SQL. Su razón principal era que los puntos de vista hacían que a un codificador irreflexivo le resultara demasiado fácil involucrar innecesariamente tablas unidas que, si el codificador lo intentaba más, podrían evitarse por completo. Implícitamente, estaba alentando la reutilización del código a través de copiar y pegar en lugar de encapsular en las vistas.

La base de datos tenía casi 600 tablas y estaba altamente normalizada, por lo que la mayoría del SQL útil era necesariamente detallado.

Varios años más tarde, puedo ver al menos un mal resultado de la prohibición: tenemos cientos de procesos almacenados densos y largos que casi no se pueden mantener.

En retrospectiva, diría que fue una mala decisión, pero ¿cuáles son sus experiencias con las vistas de SQL? ¿Los has encontrado malos para el rendimiento? ¿Alguna otra idea sobre cuándo son o no son apropiados?

Hace un tiempo, intenté mantener el código que usaba vistas construidas a partir de vistas construidas a partir de vistas ... Eso fue un problema en el a **, así que me volví un poco alérgico a las opiniones :)

Normalmente prefiero trabajar con tablas directamente, especialmente para aplicaciones web donde la velocidad es una preocupación principal. Al acceder directamente a las tablas, tiene la posibilidad de ajustar sus consultas SQL para lograr el mejor rendimiento. Los planes de trabajo "precompilados" / en caché pueden ser una ventaja de las vistas, pero en muchos casos la compilación justo a tiempo con todos los parámetros dados y las cláusulas en consideración darán como resultado un procesamiento más rápido de todos.

Sin embargo, eso no excluye puntos de vista totalmente, si se usa adecuadamente. Por ejemplo, puede usar una vista con la tabla "usuarios" unida a la tabla "users_status" para obtener una explicación textual de cada estado, si lo necesita. Sin embargo, si no necesita la explicación: use la tabla "usuarios", no la vista. Como siempre: ¡Usa tu cerebro!

Has respondido tu propia pregunta:

estaba alentando la reutilización del código a través de copiar y pegar

Reutiliza el código creando una vista. Si la vista tiene un bajo rendimiento, será mucho más fácil realizar un seguimiento que si tiene el mismo código de bajo rendimiento en varios lugares.

Hay algunos muy buenos usos para las vistas; Los he usado mucho para sintonizar y para exponer conjuntos de información menos normalizados, o para resultados de UNION-ing de selecciones múltiples en un solo conjunto de resultados.

Obviamente, cualquier herramienta de programación puede usarse incorrectamente, pero no puedo pensar en ningún momento en el que una vista mal ajustada haya causado algún tipo de inconveniente desde el punto de vista del rendimiento, y el valor que pueden proporcionar al proporcionar selecciones explícitamente sintonizadas y evitar la duplicación del código SQL complejo puede ser significativa.

A propósito, nunca me gustaron las "reglas" arquitectónicas que se basan en evitar que los desarrolladores se lastimen a sí mismos. Estas reglas a menudo tienen efectos colaterales involuntarios: el último lugar donde trabajé no permitía el uso de valores NULL en la base de datos, ya que los desarrolladores podían olvidarse de verificar nulos. Esto terminó forzándonos a trabajar con fechas "1/1/1900" y números enteros predeterminados a "0" en todo el software construido contra las bases de datos, e introduciendo una letanía de errores causados por desarrolladores trabajando alrededor de lugares donde NULL era el valor apropiado .

Las vistas han sido útiles para nosotros en su función de uso de aplicaciones basadas en la web pública que provienen de una base de datos de producción. La seguridad simplificada es la principal ventaja que vemos ya que el diseño de la tabla en la base de datos puede combinar datos confidenciales y no confidenciales dentro de la misma tabla. Un procedimiento almacenado comparte gran parte de esta ventaja, pero la vista es de solo lectura, tiene posibles ventajas de interoperabilidad y es una tarea menos compleja para los jóvenes.

Esta ventaja de abstracción de seguridad también se aplica cuando las vistas se usan para consultas ad-hoc de usuario final; esto sería una ventaja menor si tuviéramos una representación del almacenamiento de datos apropiada y plana de nuestros datos.

Las vistas son buenas para las consultas ad-hoc, del tipo que un DBA hace detrás de las escenas cuando él / ella necesita acceso rápido a los datos para ver qué está pasando con el sistema.

Pero pueden ser malos para el código de producción. Parte de la razón es que es impredecible qué índices necesitará con una vista, ya que la cláusula where puede ser diferente y, por lo tanto, difícil de sintonizar. Además, generalmente está devolviendo muchos más datos de los necesarios para las consultas individuales que usan la vista. Cada una de estas consultas podría ser ajustada y ajustada individualmente.

Hay usos específicos de vistas en casos de partición de datos que pueden ser extremadamente útiles, así que no estoy diciendo que deberían evitarse por completo. Solo digo que si una vista puede ser reemplazada por unos pocos procedimientos almacenados, estará mejor sin la vista.

Las vistas también pueden reducir el tamaño de las consultas complejas (de la misma manera que los procesos almacenados pueden).

Esto puede reducir el ancho de banda de la red para bases de datos muy ocupadas.

Mi base de datos actual estaba completamente inundada con innumerables tablas pequeñas de no más de 5 filas cada una. Bueno, podría contarlos, pero estaba desordenado. Estas tablas simplemente tenían valores de tipo constante (piense enum) y podrían combinarse fácilmente en una tabla. Luego hice vistas que simulaban cada una de las tablas que eliminé para garantizar la compactabilidad hacia atrás. Funcionó muy bien.

No soy un gran admirador de las vistas (No puedo recordar la última vez que escribí una) pero tampoco las prohibiría del todo. Si su base de datos le permite poner índices en las vistas y no solo en la mesa, a menudo puede mejorar el rendimiento un poco, lo que los hace mejores. Si está utilizando vistas, asegúrese de buscarlas en la indexación.

Realmente solo veo la necesidad de vistas para particionar datos y combinaciones extremadamente complejas que son realmente críticas para la aplicación (pensando en los informes financieros aquí donde comenzar desde el mismo conjunto de datos para todo podría ser crítico). Sé que algunas herramientas de informes parecen preferir las vistas sobre los procesos almacenados.

Soy un gran defensor de nunca devolver más registros o campos de los que necesita en una instancia específica y el uso excesivo de vistas tiende a hacer que las personas devuelvan más campos (y en demasiados casos, demasiadas uniones) de los que necesitan, lo que desperdicia recursos del sistema .

También tiendo a ver que las personas que confían en las vistas (no el desarrollador de la vista, las personas que solo las usan) a menudo no entienden muy bien la base de datos (por lo que obtendrían las uniones incorrectas si no usan la vista) y eso para mí es fundamental para escribir un buen código contra la base de datos. Quiero que las personas entiendan lo que le están pidiendo al DB que haga, no confíe en una caja negra mágica de una vista. Esa es toda la opinión personal, por supuesto, su kilometraje puede variar.

Al igual que BlaM, personalmente no los he encontrado más fáciles de mantener que los procesos almacenados.

Editado en octubre de 2010 para agregar: Desde que originalmente escribí esto, tuve la oportunidad de trabajar con un par de bases de datos diseñadas por personas adictas al uso de vistas. Peor aún, usaron vistas que llamaban vistas que llamaban vistas (hasta el punto en que finalmente llegamos al límite de la cantidad de tablas que se pueden llamar). Esta fue una pesadilla de rendimiento. Le tomó 8 minutos obtener un conteo simple (*) de los registros en una vista y mucho más para obtener datos. Si usa vistas, tenga mucho cuidado con el uso de vistas que llamen a otras vistas. Construirá un sistema que muy probablemente no funcionará bajo la carga de rendimiento normal en la producción. En SQL Server, solo puede indexar vistas que no llaman a otras vistas, entonces, lo que termina sucediendo cuando usa vistas en una cadena, es que todo el conjunto de registros debe ser creado para cada vista y no es hasta que llegue al último que se aplican los criterios de la cláusula where. Es posible que necesite generar millones de registros solo para ver tres. Puede unirse a la misma tabla 6 veces cuando realmente solo necesite unirse a ella una vez, puede devolver muchas más columnas de las que necesita en el conjunto de resultados final.

Una cosa que no se ha mencionado hasta ahora es el uso de vistas para proporcionar una imagen lógica de los datos a los usuarios finales para informes ad hoc o similares.

Esto tiene dos méritos:

Permitir al usuario soltar "tablas" que contengan los datos que esperan y que requieren usuarios relativamente no técnicos para calcular combinaciones potencialmente complejas (porque la base de datos está normalizada)
Proporciona un medio para permitir cierto grado de acceso ah hoc sin exponer los datos o la estructura a los usuarios finales.

Incluso con informes no ad-hoc, a veces es significativamente más fácil proporcionar una vista del sistema de informes que contiene los datos de referencia, separando claramente la producción de datos de la presentación de los mismos.

Usamos vistas para todas nuestras exportaciones de datos simples a archivos csv. Esto simplifica el proceso de escritura de un paquete y la incrustación de sql dentro del paquete, que se vuelve engorroso y difícil de depurar.

Usando vistas, podemos ejecutar una vista y ver exactamente lo que se exportó, sin cruces o incógnitas. Es de gran ayuda en la solución de problemas con exportaciones de datos inadecuadas y oculta cualquier combinación compleja detrás de la vista. De acuerdo, utilizamos un sistema heredado muy antiguo de un sistema basado en TERMS que exporta a sql, por lo que las uniones son un poco más complejas de lo habitual.

Veamos si puedo llegar a una analogía coja ...

"No necesito un destornillador Phillips. ¡Llevo una cabeza plana y una amoladora!"

Descartar las vistas sin control causará dolor a largo plazo. Por un lado, es más fácil depurar y modificar una sola definición de vista que enviar un código modificado.