He leído en algún lugar hace mucho tiempo. El libro establece que no debemos permitir tener una vista anidada en SQL Server. No estoy seguro de la razón por la que no podemos hacer eso o podría recordar una declaración incorrecta.
Estudiantes
SELECT studentID, first_name, last_name, SchoolID, ... FROM students
CREATE VIEW vw_eligible_student
AS
SELECT * FROM students
WHERE enroll_this_year = 1Maestros
SELECT TeacherID, first_name, last_name, SchoolID, ... FROM teachers
CREATE VIEW vw_eligible_teacher
AS
SELECT * FROM teachers
WHERE HasCert = 1 AND enroll_this_year = 1Escuelas
CREATE VIEW vw_eligible_school
AS
SELECT TOP 100 PERCENT SchoolID, school_name
FROM schools sh
JOIN
vw_eligible_student s
ON s.SchoolID = sh.SchoolID
JOIN
vw_eligible_teacher t
ON s.SchoolID = t.SchoolIDEn mi lugar de trabajo, he investigado una de nuestras aplicaciones de bases de datos internas. Revisé los objetos y descubrí que hay dos o tres capas de la pila de vistas entre sí. Eso me recordó lo que leí en el pasado. ¿Alguien puede ayudar a explicarlo?
Si no está bien hacerlo, quiero saber que está limitado solo a SQL Server o es para el diseño de bases de datos en general.
Información adicional: Actualicé un ejemplo de mi empresa. Cambio un poco para ser más general sin demasiadas técnicas (demasiadas columnas en este ejemplo). En su mayoría, la vista anidada que utilizamos se basa en una vista abstracta o agregada. Por ejemplo, tenemos una gran mesa de estudiantes con cientos de columnas. Digamos, Eligible Student Viewse basa en estudiantes que se matriculan este año. Y la vista elegible para estudiantes podría usarse en otros lugares, como en el procedimiento almacenado.
fuente
Respuestas:
Independientemente de la plataforma, se aplican las siguientes observaciones.
(-) Vistas anidadas:
son más difíciles de entender y depurar
Por ejemplo, ¿a qué columna de la tabla se refiere esta columna de vista? Déjeme excavar a través de 4 niveles de definiciones de vista ...
dificultar que el optimizador de consultas presente el plan de consultas más eficiente
Vea esto , esto , esto y esto para evidencia anecdótica. Compare esto , que muestra que el optimizador es a menudo lo suficientemente inteligente como para descomprimir correctamente las vistas anidadas y seleccionar un plan óptimo, pero no sin un costo de compilación.
Puede medir el costo de rendimiento comparando la consulta de vista con una equivalente escrita en las tablas base.
(+) Por otro lado, las vistas anidadas le permiten:
He descubierto que rara vez son necesarios.
En su ejemplo, está utilizando vistas anidadas para centralizar y reutilizar ciertas definiciones comerciales (por ejemplo, "¿Qué es un estudiante elegible?"). Este es un uso válido para vistas anidadas. Si mantiene o ajusta esta base de datos, calcule el costo de mantenerlos en comparación con el de eliminarlos.
Mantener: Al mantener las vistas anidadas, incurrirá en las ventajas y desventajas enumeradas anteriormente.
Eliminar: para eliminar las vistas anidadas:
Debe reemplazar todas las apariciones de las vistas con sus consultas base.
Debe recordar actualizar todas las consultas relevantes si su definición de estudiante / maestro / escuela elegible cambia, en lugar de simplemente actualizar la definición de vista relevante.
fuente
A veces, las vistas anidadas se utilizan para evitar la repetición de agregados. Supongamos que tiene una vista que cuenta los mensajes y los agrupa por ID de usuario, puede tener una vista sobre eso que cuenta el número de usuarios que tienen> 100 mensajes, ese tipo de cosas. Esto es más efectivo cuando la vista base es una vista indexada: no necesariamente desea crear otra vista indexada para representar los datos con una agrupación ligeramente diferente, porque ahora está pagando el mantenimiento del índice dos veces donde el rendimiento es probablemente adecuado contra la vista original.
Si estas son solo vistas anidadas donde está haciendo select * pero cambiando el orden o la parte superior, parece que esto se encapsularía mejor como un procedimiento almacenado con parámetros (o funciones con valores de tabla en línea) que un montón de vistas anidadas. EN MI HUMILDE OPINIÓN.
fuente
Las versiones posteriores de SQL (2005+) parecen mejores para optimizar el uso de las vistas. Las vistas son mejores para consolidar las reglas de negocio. EG: donde trabajo tenemos una base de datos de productos de telecomunicaciones. Cada producto se asigna a un plan de tarifas, y ese plan de tarifas puede intercambiarse, y las tarifas en el plan de tarifas pueden activarse / desactivarse a medida que las tarifas aumentan o se modifican.
Para hacerlo más fácil, podemos hacer vistas anidadas. 1st view simplemente une los planes de tarifas a sus tarifas usando las tablas que sean necesarias y devolviendo los datos necesarios que necesitarían los siguientes niveles de vistas. La (s) segunda (s) vista (s) puede aislar solo planes de tarifas activos y sus tarifas activas. O simplemente tarifas de clientes. O tarifas de empleados (para descuentos de empleados). O tarifas de clientes comerciales versus residenciales. (los planes de tarifas pueden complicarse). El punto es que la vista básica garantiza que nuestra lógica comercial general para planes de tarifas y tarifas se unan correctamente en una sola ubicación. La siguiente capa de vistas nos da más enfoque en planes de tarifas específicos (tipos, activos / inactivos, etc.).
Estoy de acuerdo en que las vistas pueden hacer que la depuración sea complicada si está creando consultas y vistas al mismo tiempo. Pero, si está utilizando una vista probada y confiable, facilita la depuración. Usted sabe que la vista ya ha pasado por el timbre, por lo que probablemente no esté causando el problema.
Sin embargo, pueden surgir problemas con sus puntos de vista. "¿Qué pasa si un producto está asociado solo a un plan de tarifas inactivo?" o "¿y si un plan de tarifas solo tiene tasas inactivas?" Bueno, eso puede quedar atrapado en el nivel inicial con una lógica que detecta los errores del usuario. "Error, el producto está en un plan de tarifas inactivo ... corrija". También podemos ejecutar auditorías de consultas para verificarlo dos veces antes de una ejecución de facturación. (seleccione todos los planes y únase a la vista de plan de tarifas activo, solo devuelva los planes que no obtengan un plan de tarifas activo como problemas que deben abordarse).
Lo bueno de esto es que las vistas le permiten condensar en gran medida las consultas para informes, facturación, etc. Puede tener una vista de cuenta de cliente, luego una vista de segundo nivel de clientes activos. Combine eso con una vista de la dirección del cliente. Equipo que con una vista de producto (s) (unido en qué producto (s) tiene el cliente). Combine eso para ver el plan de tarifas de productos. Equipo que con vista de las características del producto. Ver, ver, ver, cada prueba y error para garantizar la integridad. Su consulta final usando las vistas es muy compacta.
editar:
Como un ejemplo de cómo la vista hubiera sido mejor que una simple consulta de tablas ... tuvimos un contratista temporal que hizo algunos cambios. Le dijeron que había puntos de vista para las cosas, pero decidió aplanar todas sus consultas. Facturación estaba eliminando algunas de sus consultas. Siguieron obteniendo múltiples tarifas y planes sobre cosas. Resulta que a sus consultas les faltaban criterios para permitir que solo se facturaran las tarifas si se encontraban entre las fechas de inicio y finalización en las que se suponía que el plan tarifario usaría esas / esas tarifas durante. Ups Si hubiera utilizado la vista, ya habría tenido en cuenta esa lógica.
Básicamente, debe sopesar el rendimiento frente a la cordura. Tal vez pueda hacer todo tipo de cosas elegantes para aumentar el rendimiento de una base de datos. Pero, si eso significa que es una pesadilla para una nueva persona hacerse cargo / mantener, ¿realmente vale la pena? ¿Realmente vale la pena que el chico nuevo tenga que jugar whack-a-mole para encontrar todas las consultas que necesitan para cambiar su lógica (y arriesgarse a que las olvide / los toque con el dedo gordo) b / c alguien decidió que las vistas son "malas" y ¿No consolidó alguna lógica comercial central en una que pudiera usarse en cientos de otras consultas? Realmente depende de su negocio y su equipo de TI / IS / DB. Pero, preferiría la claridad y la consolidación de fuente única sobre el rendimiento.
fuente
El verdadero problema no son las vistas anidadas en sí mismas. El verdadero problema es la proliferación de vistas anidadas a medida que los desarrolladores agregan ajustes adicionales a las vistas existentes. He encontrado consultas con una vista anidada de 4 capas que realmente se unieron a una de las vistas en su definición. Nuestra tendencia a tomar el camino fácil en lugar de analizar y resolver un problema es la raíz del problema.
fuente
En mi entorno, replicamos muchas tablas del servidor de producción al servidor de informes. En el servidor de informes tenemos muchas vistas que se basan en tablas de producción replicadas Y están anidadas. Antes de que comience la replicación, tenemos que eliminar todas las vistas para hacer posible la replicación (usamos drop and create porque la estructura de las tablas a menudo cambia en la producción). Una vez que finaliza la replicación, tenemos que reconstruir todas las vistas.
Ahora esta es la parte divertida: dado que muchas de las vistas están anidadas, tenemos que reconstruirlas en un orden específico. Al realizar cualquier cambio en la definición de vistas, debemos prestar atención para mantener el orden correcto de reconstrucción. Es un desastre total. Recomiendo encarecidamente el uso de vistas anidadas si usa la replicación o simplemente suelta y reconstruye sus tablas, que son el origen de las vistas.
El rendimiento es otra cosa. Las vistas que se basan en otras vistas no son más que consultas múltiples para ejecutar. Es más fácil juntar la consulta más grande, crear un trabajo y hacer una tabla. Más fácil y mejora el rendimiento.
fuente