¿La mejor manera de organizar las consultas SQL almacenadas en su código? (o deberías?) [cerrado]

13

Estoy seguro de que no soy el único que se siente frustrado cuando ve una página de código llena de consultas SQL. ActiveRecord y otros patrones de ORM ayudan a mitigar una buena cantidad de SQL utilizado en un proyecto, pero en muchos casos de consultas complejas, el uso de SQL es aparentemente inevitable.

¿Estoy buscando opiniones sobre cómo deberían organizarse las consultas SQL con el resto del código (o externamente) para evitar que se dispersen por todo el lugar? Una idea obvia es el uso de Vistas, pero a menudo las Vistas pueden ser una fuente de problemas de rendimiento cuando se trata de múltiples tablas indexadas grandes, etc.

EDIT 1 - Supongo que ya lo tienes separado en la capa modelo

    
pregunta jellyfishtree 13.12.2010 - 01:59

3 respuestas

10

Para mí, SQL es una parte fundamental (en muchos casos, la mayoría) del código de lógica de negocios. Si intenta separarlo del código que opera en los datos devueltos, es más propenso a desequilibrar la comprensibilidad y el mantenimiento del código.

Mientras lo miro, leer datos, procesar datos, escribir datos, buscar datos ... son todas operaciones similares, y es mejor mantenerlas en el mismo lugar.

Si comienza a detectar una duplicación de esfuerzos con las consultas, quizás necesite una vista de base de datos o un objeto que pueda encapsular ese aspecto del acceso a la base de datos.

Otro consejo es tener un buen método de consulta de base de datos. En el software que escribo (PostgreSQL, MySQL, SQL Server), me he asegurado de que la mayor parte de mis operaciones de consulta puedan tener lugar como una sola declaración de código.

GetValue(SQL, [transaction], [array_of_params])
GetRow(SQL, [transaction], [array_of_params])
GetRowList(SQL, [transaction], [array_of_params])
GetValueList(SQL, [transaction], [array_of_params])
Execute(SQL, [transaction], [array_of_params])

Esas son (aproximadamente) las llamadas a la función principal que aseguro que forman parte de mi "objeto de conexión". Depende del idioma, de lo que realmente impliques, pero mi punto es que sea realmente simple e indoloro.

En resumen, trata a SQL como una parte nativa de la programación y no se abstrae por abstracción.

    
respondido por el gahooa 13.12.2010 - 02:48
0

En general, tener una capa de modelo separada es el mejor enfoque. Hay una serie de patrones de diseño empresarial que ofrecen formas de diseñar esto.

    
respondido por el Jason Baker 13.12.2010 - 02:05
0

Podría ser una buena idea separar la capa del modelo en 3 subcapas: "entidades", "repositorios" y "servicios". Esto le dará una separación de las preocupaciones y reunirá SQL en un solo lugar, fuera de su lógica empresarial.

En este escenario, todo el código de recuperación de datos, incluido el SQL complejo, se ubicará en los repositorios. Por lo tanto, el objetivo de repositorio es ocultar declaraciones SQL complejas detrás de métodos autoexplicativos como getUsersWithActiveSubscription() .

La entidad abstrae los nombres de los campos de la tabla de la base de datos real con captadores y definidores, puede proporcionar alguna conversión de datos entre los tipos de campo de la base de datos y los tipos disponibles en su aplicación / lenguaje de programación. Si su ORM lo admite, las entidades pueden manejar asociaciones.

La capa de servicio es el lugar para la lógica de negocios. El servicio recupera entidades que utilizan repositorios, actúa sobre ellas y las almacena de nuevo.

    
respondido por el GerKirill 27.07.2014 - 22:08

Lea otras preguntas en las etiquetas