Proporcionaré una respuesta basada en el archivo Léame de un generador de SQL personalizado mío ( Dialecto )
(sigue el texto sin formato, se eliminaron las referencias específicas de la biblioteca)
Requisitos
- Admite múltiples proveedores de bases de datos (por ejemplo, MySQL, PostgreSQL, SQLite, MS SQL / SQL Server, Oracle, DB2, ..)
- Se extiende fácilmente a nuevas bases de datos (preferiblemente a través de una configuración de configuración independiente de la implementación)
- Modularidad y transferibilidad independiente de la implementación
- API flexible e intuitiva
Caracteristicas
- plantillas gramaticales
- soporte de vistas suaves personalizadas
- abstracción db, modularidad y transferibilidad
- plantillas preparadas
- escape de datos
Creo que las características y requisitos anteriores esbozan las razones por las que uno usaría un generador de abstracción SQL
La mayoría de las características anteriores son compatibles con la mayoría de los constructores de SQL (aunque no creo que todos los listados sean compatibles, que yo sepa)
Ejemplos de casos de uso:
- Plataforma CMS capaz de funcionar (sin cambio de código subyacente) con múltiples proveedores de bases de datos
- Código de aplicación personalizado en el que el proveedor de bases de datos puede cambiar y / o los esquemas de dB son dinámicos (esto significa que muchas consultas no pueden codificarse pero aún deben abstraerse lo suficiente para que el código sea robusto para los cambios)
- Creación de prototipos con otra base de datos que no sea la utilizada en producción (requeriría una base de código duplicada al menos para parte del código)
- El código de la aplicación no está estrechamente acoplado a un proveedor o implementación de DB específicos (incluso dentro del mismo proveedor de DB, por ejemplo, diferentes versiones del proveedor de DB), por lo tanto, es más robusto, flexible y modular
- El marco mismo maneja muchos casos habituales de consultas y escapes de datos y, por lo general, esto es óptimo y más rápido
Finalmente, un ejemplo de un caso de uso que tuve. Estaba creando una aplicación en la que el esquema de base de datos subyacente (wordpress) no era adecuado para el tipo de consultas de datos que debían realizarse, además de que algunas de las tablas de WP (por ejemplo, publicaciones) tenían que usarse (por lo tanto, tener tablas completamente nuevas para todos los datos de la aplicación no era una opción).
En ese caso, poder hacer una aplicación similar a MVC donde el modelo podría ser consultado por condiciones personalizadas / dinámicas hizo que la codificación de consultas fuera casi una pesadilla. Imagina tener que admitir consultas de hasta 2-3 tablas con combinaciones y filtrar las condiciones para ver qué tabla unir con qué y también cuidar los alias necesarios, etc.
Es evidente que se trataba de un caso de uso abstracción de consulta y, aún más, que necesitaba (o al menos en gran medida benefició de) que tiene una capacidad de definir vistas personalizadas suaves (un conglomerado de tablas unidas como si fueran una tabla personalizada adecuada para el modelo) . Entonces fue mucho más fácil, más limpio, modular y flexible. En otro aspecto, la aplicación (código) también usó la capa de abstracción de consulta como una herramienta de normalización (esquema db) . Como algunos dicen, era a prueba de futuro .
Si mañana las personas deciden que necesitan algunas opciones o datos adicionales, es muy fácil agregarlos al modelo en un par de líneas y funcionar bien. Además, si mañana las personas deciden que ya no quieren usar wordpress (ya que la aplicación está acoplada libremente a wordpress como complemento), también es relativamente fácil cambiar ( solo la definición de) los modelos en un par de líneas de código para adaptarse al nuevo esquema.
¿Ves lo que quiero decir?