Abstracción de la base de datos: ¿se está exagerando?

Después de estar expuesto a numerosas capas de abstracción de bases de datos, empiezo a preguntarme cuál es el punto de que cada biblioteca invente su propio paradigma diferente para acceder a los datos. Elegir un nuevo DAL se siente como aprender un nuevo idioma nuevamente, cuando generalmente todo lo que quiero hacer es convencer a la capa para que genere una consulta SQL que ya he escrito en mi cabeza.

Y eso sin siquiera tocar la legibilidad después del hecho:

# Exhibit A:  A typical DAL
rows = db(db.ips_x_users.ip_addr == '127.0.0.1')
    .inner_join(db.ips_x_users.user_id == db.users.id)
    .select(order=(db.ips_x_users.last_seen, 'desc'), limit=10)

# Exhibit B:  Another typical DAL
rows = db.ips_x_users
    .join(db.users, on=db.ips_x_users.user_id == db.users.id)
    .filter(db.ips_x_users.ip_addr == '127.0.0.1')
    .select(sort=~db.ips_x_users, limit=10)

# Exhibit C:  A hypothetical DAL based on standard SQL syntax
rows = db('''SELECT * FROM ips_x_users
             INNER JOIN users ON
                 (ips_x_users.user_id = users.id)
             WHERE ips_x_users.ip_addr = ip
             ORDER BY last_seen DESC LIMIT 10''', ip='127.0.0.1')

¿Qué hay de malo con la sintaxis SQL estándar? Fue creado para un propósito específico, y se adapta perfectamente a ese propósito. Tal vez solo soy yo, pero entiendo el fragmento C con mucha más facilidad que los dos primeros. Las palabras clave renombradas y los trucos de sintaxis son lindos, pero en mi opinión, cuando se trata de eso, no facilitan la recuperación de filas para el codificador.

Esto probablemente parecía una larga perorata, pero no es una pregunta real aquí. Dado que cada DAL parece inventar un nuevo DSL para consultas en lugar de simplemente analizar SQL probado y verdadero, debe haber beneficios de usar una sintaxis diferente o deficiencias en la sintaxis SQL estándar que no sé que existen. ¿Alguien podría señalar lo que estoy pasando por alto aquí?

El problema más fundamental del uso común de SQL es que las consultas SQL son cadenas, que de alguna manera están compuestas de otro idioma. Aquí es de donde provienen las inyecciones SQL y otras vulnerabilidades y WTF (su ejemplo está muy mal elegido, porque su consulta en realidad no tiene ningún parámetro).

El siguiente problema es en realidad un corolario: si solo tiene algo de SQL escrito en su código, el compilador no puede hacer nada al respecto. Errores como errores tipográficos en los nombres de columna solo aparecerán en tiempo de ejecución. Esto es básicamente, por qué no desea solo una representación de cadena de su consulta en su código fuente, sino algo que el compilador puede analizar estáticamente para evitar el 95% de todos los errores de facepalm.

Y el último problema ocurre cuando intenta asignar una base de datos relacional a su semántica de lenguaje y modelo de programación: los RDBMS no funcionan bien con OOP (o recuperación de datos de navegación). En realidad, esta es una idea bastante terrible que combina esos dos, pero de eso se tratan todos los DAL orientados a objetos para bases de datos SQL (es decir, ORM). Pero todas estas capas de abstracción están condenadas a filtrarse. Creo que esta es básicamente la razón por la que hay tantos: porque trabajas con ellos, ves que tienen fallas, te pones a escribir un DAL que lo haga bien y finalmente falle.

Entonces, aunque los problemas uno y dos sugieren tener DAL que eliminen SQL, el problema tres implica que no hay una solución directa de tener uno (al menos para OOP) y, por lo tanto, siempre habrá un mar de DAL con diferentes fortalezas y limitaciones. Al final, todo lo que puede hacer es elegir cuidadosamente algunos y atenerse a ellos.

Está pasando por alto el hecho obvio de que no todas las plataformas de bases de datos aceptan la misma sintaxis SQL, por lo que incrustar sentencias SQL en su aplicación simplemente no funcionará para todas las plataformas de bases de datos. Si alguna vez necesita soportar múltiples plataformas de bases de datos, tendrá que repensar la mayoría (si no todas) de estas declaraciones SQL.

Siento que SQL está experimentando el mismo cambio importante que tuvieron los punteros hace 10 años. Hay un intento continuo de eliminar el trabajo manual con SQL y llevarlo a un nivel de abstracción más alto. Lo mismo sucedió con los punteros y la administración manual de memoria hace muchos años.

Dado que el trabajo está actualmente en progreso, disfruta viendo muchos enfoques diferentes sugeridos, probados, abandonados e integrados. Estoy seguro de que veremos más antes de algún tipo de enfoque común o un estándar de la industria si lo desea se manifiesta.

Sin duda, le da una ventaja cuando puede manipular el código de acceso a datos al mismo nivel y con el mismo paradigma que aplica cuando trabaja con su código de aplicación.

En pocas palabras: simplificación, agilidad, rapidez, estos son los objetivos.

Joel había escrito un buen artículo hace 10 años: no dejes que los astronautas de la arquitectura te asusten

Creo que es exactamente el caso. Estaba usando la capa de abstracción en mis propias aplicaciones desde que encontré un patrón y fue fácil para mí hacerlo de esta manera. Pero fue mi DAL. Conocía cada línea en el código fuente => control total. Pero no sugeriría usar ese marco a nadie fuera de mi equipo / proyectos.

Cuando usa algo así, es importante saber cómo se implementa, eso significa que debe pasar mucho tiempo aprendiendo la biblioteca / herramienta. Si no tienes tiempo para aprenderlo, no lo uses. Incluso si parece muy fácil desde el principio.