Mejores prácticas para consultas SQL en línea

Question

Estoy trabajando con un sitio web asp.net que utiliza muchas consultas SQL en línea ... y me pregunto si es mejor crear las consultas en línea sobre la marcha:

int i = 500; 

    using (SqlConnection conn = new SqlConnection(connStr)) 
    { 
     SqlCommand com = new SqlCommand(conn); 
     ... 
     com.CommandText = "select from table where column < @parameter"; 
     ... 
    } 

O para tener una clase para albergar todas las consultas necesarias para la aplicación. Algo como esto:

class SqlQueries 
{ 
    private string query1 = 
      "select * from tblEmployees where EmployeeName = @EmployeeName"; 

    private string query2 = 
      "select * from tblVacation where EmployeeName = @EmployeeName"; 

    public string Query(string s) 
    { 
     string str = string.Empty; 

      switch (s) 
      { 
       case "query1": 
        str = query1; 
        break; 
       case "query2": 
        str = query2; 
        break; 
      }  

    return str;  

    } 
} 

¡Gracias!

Answer 1

He usado muchas consultas de ADO.NET en mi época y siempre he usado el primer método. El segundo método es una idea interesante, pero puede ser engorroso editar esas consultas si se encuentra en otro lugar del código que lo utiliza. También hace que sea más difícil ver qué hace una consulta en un lugar particular del código. Ejemplo:

string sql = "Update User set age = @age where UserId = @UserId"; 

dice un desarrollador de lo que está sucediendo, mientras que:

string sql = SqlQueries.Query("updateAge"); 

deja preguntas acerca de lo que la mesa/columnas están siendo actualizadas. Además, con la primera, sabrá exactamente qué parámetros se deben agregar.

Si está escribiendo esta consulta en varios lugares que podrían cambiar las cosas

Answer 2

Creo que está bien tener las consultas "en línea", siempre y cuando no se repitan en varios lugares. Si eso comienza a suceder, es posible que desee comenzar a crear clases de consulta.

Answer 3

No es terrible poner el literal directamente en el método, siempre que siempre llame al mismo método cada vez que quiera ejecutar esa consulta. Sin embargo, si vas a copiar ese literal de cadena en varios lugares en tu código, definitivamente se prefiere una constante. Sin embargo, en lugar de tomar una cadena como argumento para el método Query en su segundo ejemplo, debería tomar un valor de enumeración.

Sin embargo, si está utilizando el segundo método que describió, le preguntaría por qué no solo comienza a usar procedimientos almacenados.

Answer 4

En ambos casos las que en última instancia está construyendo/ir a buscar String, que pasará a CommandText. Entonces no habría tal diferencia. Lo único que debe tener en cuenta en su caso es cómo mantendrá el código o cómo otras personas entenderán su código.

Answer 5

Si va a utilizar SQL en línea, al menos no lo ponga en el código de la página web, ya que será doloroso cuando haga cambios en la base de datos para saber a qué afecta. Poner todas las consultas en una sola clase puede ser un poco desorganizado, pero si las agrupa por clases funcionales (como clases de administrador para sus objetos de negocio) podría ser más fácil de tratar.

Answer 6

Recomendaría utilizar procedimientos almacenados como una solución mucho mejor a su problema que las consultas en línea codificadas. Si tiene que cambiar la consulta en una fecha posterior, no tiene que volver a generar su aplicación, por lo que los errores en su consulta se pueden corregir sin necesidad de implementar toda la aplicación. La segunda opción que tienes allí es una pesadilla de mantenimiento esperando a suceder. Todo se ve muy bien cuando tienes una o dos consultas, pero eso empieza a parecer un poco más feo cuando tienes decenas o cientos allí.El código parece que es C#, por lo que recomiendo la salida a la biblioteca Microsoft Enterprise,

http://msdn.microsoft.com/en-us/library/ff632023.aspx

Es posible que tenga que descargar una versión diferente dependiendo de la versión del marco .NET está desarrollando con.

Answer 7

Si usted absolutamente tiene que tener SQL "en línea", en contraposición a los procedimientos almacenados (y he hecho esto para aplicaciones de tipo de utilidad que simplemente interactúan con una base de datos, en lugar de propia ella), sugeriría poner su SQL en un embedded resource file. Esto hará que sus consultas sean más fáciles de mantener (aunque aún necesitará volver a compilar su aplicación para realizar cambios).

Answer 8

Si sus consultas son más largas que una o dos líneas, debería considerar colocarlas en su propio archivo .sql. Establezca la acción de compilación en el archivo al recurso incrustado y acceda a él con una llamada a GetManifestResourceStream(). De esta forma, elevará su sql al estado de un lenguaje apropiado, con resaltado de sintaxis, validación e intellisense (cuando conecta VS a su base de datos). Huelga decir que esto facilita enormemente el mantenimiento.

Si todo esto parece una molestia, agarre mi extensión VS, QueryFirst. Cree sus archivos .sql con la plantilla proporcionada y se conectarán automáticamente para su compilación. Pero no le importará porque solo tendrá acceso a las consultas a través de las clases generadas.

Sql es el único lenguaje de computadora que puedo pensar que aceptamos ver recortado en literales de cadena. Debería ser un escándalo.