¿Usar SQL View o SQL Query?

Question

Estoy trabajando en una aplicación para obtener datos de un servidor MS-SQL (2005). En el texto de comando, puedo pasar una consulta SQL como esto:

string query = "SELECT T1.f1, T1.f2, T2.f3 FROM table1 T1 join table2 T2" + 
    "on T1.id = T2.id AND T1.dt = T2.dt ..." 
.... 
cmd.CommandText = query; 

también pude poner la consulta como una visión en mi servidor SQL como esto:

CREATE VIEW V1 AS 
    "SELECT T1.f1, ..." 

entonces puedo usar la vista en una consulta simplificada como esta:

string query = "SELECT f1, f2, f3 FROM V1"; 
.... 
cmd.CommandText = query; 

No estoy seguro de cuál es la mejor manera. ¿Será la vista más rápida que una consulta SQL? Por cierto, la consulta que muestro aquí es una simplificada. La consulta real SELECT es más complicada.

Answer 1

Me gustaría crear una vista por varias razones

A) Una visión bien construido hace tienden a realizar más rápido que una consulta, aunque con la optimización de consultas puede que no note mucha diferencia.

B) Mantiene el conocimiento de la estructura de la base de datos, agregando una buena capa de abstracción (como nota al margen, considere usar un procedimiento almacenado en lugar de una consulta en línea).)

C) Si necesita realizar un cambio estructural en la base de datos, puede mantener la vista constante sin necesidad de reconstruir el código.

MODIFICACIÓN Voy a modificar esta respuesta a la luz de algunos de los comentarios con el fin de aclarar algunos puntos ...

Es absolutamente cierto que una vista estándar no proporciona ninguna ganancia en el rendimiento real, sobre una consulta. Una vista estándar se materializa en tiempo de ejecución, lo que esencialmente no la hace diferente de una forma conveniente de ejecutar una consulta de la misma estructura. Sin embargo, una vista de índice se materializa de inmediato y los resultados se conservan en el almacenamiento físico. Al igual que con cualquier decisión de diseño, el uso de una vista indexada debe considerarse cuidadosamente. No hay almuerzo gratis; La multa que paga por el uso de vistas indexadas se presenta en forma de requisitos de almacenamiento adicionales y gastos generales asociados con el mantenimiento de la vista cuando hay cambios en la base de datos subyacente.Estos se utilizan mejor en instancias de unión compleja y agregación de datos comúnmente utilizada de múltiples tablas y en casos en los que se accede a los datos con mucha más frecuencia de la que se cambian.

También estoy de acuerdo con los comentarios sobre cambios estructurales: la adición de nuevas columnas no afectará la vista. Sin embargo, si los datos se mueven, normalizan, archivan, etc., puede ser una buena forma de aislar dichos cambios de la aplicación. Estas situaciones son RARAS y se pueden obtener los mismos resultados mediante el uso de procedimientos almacenados en lugar de una vista.

Answer 2

O puede utilizar un procedimiento almacenado. El uso de un proceso almacenado permitirá que SQL guarde en caché el plan de ejecución. Creo que lo mismo es cierto de una vista. Su primer método (consulta ad-hoc) probablemente será el menos eficiente.

Answer 3

La vista es probablemente una mejor.

De esta manera, puede modificar la consulta (para la optimización) en una fecha posterior sin tener que cambiar el código.

Answer 4

La vista puede ser más rápido, porque está solicitando una cadena de comando más corta, pero la diferencia va a ser intrascendente.

La diferencia real y el valor de Views es que, al igual que las funciones y las subrutinas, son reutilizable.

Answer 5

No hay diferencia en el rendimiento (a menos que el texto de la consulta sql sea realmente gigantesco e incurra en un costo en el cable).

Answer 6

En general he encontrado que es mejor utilizar vistas por varias razones:

• consultas complejas pueden obtener difícil de leer en el código
• Puede cambiar la vista sin tener que recompilar
• relacionada con ese , puede gestionar los cambios en la estructura de la base de datos subyacente en la vista sin que toque el código, siempre que se devuelvan los mismos campos

Probablemente haya más motivos, pero en este punto nunca escribiría una consulta directamente en el código.

También debe buscar en algún tipo de tecnología ORM (Object Relational Mapper) como LINQ to SQL (L2S). Le permite usar consultas tipo SQL en su código, pero todo se abstrae a través de objetos creados en el diseñador L2S.

(En realidad, estoy moviendo nuestros objetos L2S actuales para que se queden sin vistas. Es un poco más complicado porque las relaciones no se dan también ... pero me permite crear un conjunto de objetos que se ejecuta en 2 bases de datos y mantiene todo muy bien resumido para poder cambiar los nombres de las tablas subyacentes y corregir las convenciones de nomenclatura.)

Answer 7

Para mí, la ventaja de las vistas es que puede aplicarles un contexto de seguridad. O en escenarios extremos puede usar vistas divididas distribuidas por razones de rendimiento. De lo contrario, complejizan el control de versiones. Ahora debe asegurarse de que se implemente la versión correcta de la vista, así como la nueva compilación de su dll de acceso a datos.

Solía ​​decir que los procs almacenados eran el camino a seguir porque se a) compilaban (más rápido) yb) un límite de seguridad. En el mundo real, esto a menudo es una optimización prematura. El texto del comando SQL enviado por el cliente suele ser suficientemente relevante (además de más fácil de versionar e implementar) y de control de acceso a nivel de tabla, o incluso la base de datos completa es adecuada en muchos casos.

Answer 8

Las vistas no son una función de rendimiento. Existen para reducir el número de combinaciones y permitirle desnormalizar sin desnormalización.

En otras palabras, utilice el que haga que su código sea el más simple y no cambie por motivos de rendimiento a menos que tenga buena razón para hacerlo. Este tipo de optimizaciones generalmente no lo vale.

Answer 9

A menos que se ajuste al perfil en el segundo párrafo, le recomendaría que se mantenga alejado de las vistas. Son engañosamente atractivos como una buena forma de abstraer la funcionalidad subyacente. Pero el problema es que una vez que los desarrolladores comienzan a crear vistas, tienden a comenzar a crear vistas diferentes para cada combinación posible de tablas y campos, y termina siendo un desorden explosivo descoordinado. El DBA tiene que mantenerlos a todos porque no hay forma de decir cuáles se usan realmente y cuáles no, y los desarrolladores terminan escribiendo sus propias combinaciones de todos modos porque es más fácil que atravesar y descifrar qué vista existente utilizar.

IMO, la única buena razón para usar vistas (y una bastante común) es si el DBA necesita tener libertad para modificar las tablas subyacentes sin romper el código de cliente existente. Obviamente, esto solo es posible si esa lógica está en el lado DB en una vista o proceso. Si eso se aplica a usted, continúe y use una vista. De lo contrario, recomendaría una forma diferente de ver las cosas.

El poder de una vista es la abstracción que crea. Pero el hecho es que la abstracción es utilizada solo por el cliente, no por el propio DB. Por lo tanto, me parece mejor poner esa abstracción en el lado del cliente. Entonces, en lugar de una vista, simplemente defina una macro o generador de cadenas en algún lugar del código del cliente que creará su declaración de selección para usted. Puede hacer esto simple al principio y progresivamente más complejo a medida que avanza su aplicación. De esta forma, mantendrá la abstracción y la reutilización que ofrecería una vista, pero evitará la explosión de puntos de vista y los cuellos de botella de comunicación desarrollador-DBA.