Almacenamiento de SQL dinámico en archivos de texto frente a código en línea

7

Nuestro equipo de Arquitectura está proponiendo un marco que vería que nuestras consultas SQL pasaran de cadenas codificadas dentro de nuestras aplicaciones, a un sistema basado en archivos donde las invocaríamos con llamadas a funciones. Nuestra aplicación hace un uso intensivo de consultas SQL que van desde lo mundano a muy complejo. Esta es una solución .NET.

La idea es que cada consulta se escriba en archivos de texto, y podríamos etiquetar campos, uniones y condiciones con atributos. Al llamar a nuestras funciones de SQL, podríamos pasar argumentos para activar / desactivar estos atributos según nuestra lógica de negocios, permitiendo solo las partes del SQL que necesitamos ejecutar.

Aunque me gusta la idea de abstraer nuestro SQL, soy escéptico de que este sistema genere beneficios tangibles. El principal impulsor de esto es nuestra experiencia pasada en la que muchos programadores crearon algunas funciones de SQL dinámicas masivamente complicadas que eran imposibles de entender. La idea es que esto facilitará la definición de sus consultas, hará que todas las consultas sean más fáciles de probar y que defina claramente la lógica de negocios involucrada. No estoy seguro de si esto sobrevivirá a la prueba de la realidad.

Me gustaría recibir comentarios sobre las ventajas y desventajas de este enfoque.

Además, antes de que alguien lo sugiera, el Entity Framework fue rechazado debido al soporte cuestionable de nuestro proveedor de base de datos (Teradata).

    
pregunta Brett Emerson 21.12.2012 - 15:31

4 respuestas

4

Si su problema es "imposible de entender" SQL, concéntrese en ese problema. No puedo imaginar que SQL con atributos haga algo para que sea más fácil de entender.

En su lugar, creará una carga de mantenimiento en los atributos de análisis, etc. en un lenguaje ya complejo como SQL. Tarde o temprano, tus extensiones evitarán que uses alguna buena función de base de datos. ¿Cuánta capacitación se necesita para enseñar a los nuevos empleados / contratistas su versión de SQL? Los archivos adicionales crean un proceso de implementación más complicado y posibles problemas de soporte. ¿Cómo sabe la versión del archivo que está en uso o si ha sido alterado por el cliente o su propio soporte para resolver otro problema? Todo se puede resolver, por supuesto, pero solo usted sabe si vale la pena.

Pase su tiempo configurando primero pautas estrictas para escribir SQL legible / mantenible. Una vez que esté en su lugar y todos estén de acuerdo con las reglas, puede pasar al siguiente problema.

Lo que es sql legible y mantenible varía pero aquí hay un subconjunto de nuestras reglas. (Para sql-server)

  • debe poder copiar / pegar fácilmente el código en / desde la base de datos y ejecutarlo Es decir. No hay concatenaciones de cadenas de variables en el código. Use parámetros o cadena. Reemplace donde los parámetros no están permitidos en sql.
  • una columna por línea con la tabla / alias
  • explícito AS
  • ansi se une
  • alias descriptivos (no t1, t2, etc.)
  • use CTE / CROSS APPLY para reducir la complejidad
  • use parámetros con nombre descriptivo para ambas variables y números "mágicos".
respondido por el adrianm 21.12.2012 - 23:19
4

Me encontré con este mismo dilema en mi trabajo hace un tiempo. Recibí el mismo consejo que usted, y esto es lo que pensé al respecto:

Pros:

  • Las consultas SQL se pueden probar por sí mismas, separadas del código de la línea principal.
  • Sus consultas se pueden modificar sin tener que volver a compilar.

Contras:

  • SQL es código. Me resulta más fácil de administrar cuando todo el código que hace algo está en el mismo lugar.
  • Me parece raro que modifiques una consulta SQL sin un cambio correspondiente en el código de la línea principal.

Decidí que los contras superaban a los profesionales y dejó el SQL en la fuente de la línea principal . Ha pasado casi un año desde que tomé esa decisión y no me he arrepentido una vez.

    
respondido por el Kristo 21.12.2012 - 15:42
2

Si dijiste que los arquitectos querían que extrajeras el SQL y lo pusieras en procedimientos almacenados dentro de la base de datos, habría dicho "¡Dales una galleta a los niños!". Pero pasar de SQL ensamblado a través de la construcción de cadenas a SQL ensamblado a través de plantillas es un paso muy pequeño para merecer una recompensa.

    
respondido por el Ross Patterson 21.12.2012 - 23:31
0

One BIG Pro.

Puede admitir múltiples DB's simplemente intercambiando los archivos SQL. Así que tiene varios conjuntos de código SQL para los diferentes DB que desea admitir.

    
respondido por el Morons 21.12.2012 - 16:57

Lea otras preguntas en las etiquetas