Astrazione del database - è esagerata?

Dopo essere stato esposto a numerosi livelli di astrazione del database, sto iniziando a chiedermi quale sia il punto di ogni libreria che inventa il proprio diverso paradigma per accedere ai dati. Raccogliere un nuovo DAL è come imparare di nuovo una nuova lingua, quando di solito tutto ciò che voglio fare è convincere il livello a generare una query SQL che ho già scritto nella mia testa.

E questo senza nemmeno toccare la leggibilità dopo il fatto:

# 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')

Cosa c'è di sbagliato nella sintassi SQL standard? È stato creato per uno scopo specifico e si adatta perfettamente a quello scopo. Forse sono solo io, ma capisco lo snippet C molto più prontamente dei primi due. Le parole chiave rinominate e i trucchi di sintassi sono carini, ma IMO, quando si tratta di esso, non facilitano il recupero delle righe per il programmatore.

Questo probabilmente sembrava un lungo sfogo, ma qui c'è una vera domanda. Dal momento che ogni DAL sembra inventare un nuovo DSL per le query piuttosto che semplicemente analizzare il vero e proprio SQL, ci devono essere vantaggi dell'utilizzo di una sintassi diversa o carenze nella sintassi SQL standard che non capisco ci siano. Qualcuno potrebbe indicare cosa sto trascurando qui?

Il problema fondamentale dell'uso comune di SQL è che le query SQL sono stringhe, che sono in qualche modo composte da un'altra lingua. È qui che provengono le iniezioni di SQL, altre vulnerabilità e WTF (il tuo esempio è scelto in modo piuttosto scorretto, poiché la tua query non ha alcun parametro).

Il prossimo problema è in realtà un corollario: se hai solo un po 'di SQL scritto nel tuo codice, il compilatore non può farci nulla. Errori come errori di battitura nei nomi delle colonne verranno visualizzati solo in fase di esecuzione. Questo è fondamentalmente il motivo per cui non vuoi solo una rappresentazione in formato stringa della tua query nel tuo codice sorgente, ma qualcosa che il compilatore può analizzare staticamente per prevenire il 95% di tutti i bug di facepalm.

E l'ultimo problema si verifica quando si tenta di mappare un database relazionale sulla semantica della lingua e sul modello di programmazione: gli RDBMS non vanno bene insieme con OOP (o recupero dei dati di navigazione). In realtà, questa è un'idea piuttosto terribile che combina quei due, ma è ciò su cui si basano tutti i database DAL per SQL orientati agli oggetti (ovvero ORM). Ma tutti questi strati di astrazione sono condannati a perdere. Penso che questo sia fondamentalmente il motivo per cui ce ne sono così tanti: poiché lavori con loro, vedi che sono imperfetti, hai deciso di scrivere un DAL che fa bene e alla fine fallisce.

Quindi, mentre i problemi uno e due suggeriscono di avere DAL che eliminano SQL, il problema tre implica che non esiste una soluzione diretta per averne uno (almeno per OOP) e quindi ci sarà sempre un mare di DAL con diversi punti di forza e limitazioni. Alla fine, tutto ciò che puoi fare è scegliere con cura alcuni e attenersi a loro.

Stai trascurando il fatto ovvio che non tutte le piattaforme di database accettano la stessa sintassi SQL, quindi l'incorporamento delle istruzioni SQL in tutta l'applicazione non funzionerà per tutte le piattaforme di database. Se hai mai bisogno di supportare più piattaforme di database, dovrai ripensare la maggior parte (se non tutte) di queste istruzioni SQL.

Sento che SQL sta vivendo lo stesso grande cambiamento che i puntatori sono stati 10 anni fa. È in corso un tentativo di eliminare il lavoro manuale con SQL e portarlo a un livello di astrazione più elevato. Lo stesso è accaduto con i puntatori e la gestione manuale della memoria molti anni fa.

Poiché il lavoro è attualmente in corso, ti piace vedere molti approcci diversi suggeriti, provati, abbandonati e integrati. Sono sicuro che ne vedremo di più prima di una sorta di approccio comune o di uno standard del settore se lo desideri si manifesta.

Ti dà sicuramente un vantaggio quando puoi manipolare il codice di accesso ai dati allo stesso livello e con lo stesso paradigma che applichi quando lavori con il tuo codice dell'applicazione.

In poche parole: semplificazione, agilità, rapidità, questi sono gli obiettivi.

Joel aveva scritto un bell'articolo 10 anni fa: Non lasciare che gli astronauti dell'architettura ti spaventino

Penso che sia esattamente il caso. Stavo usando il livello di astrazione nelle mie applicazioni da quando ho trovato uno schema ed è stato facile per me fare così. Ma era il mio DAL che conoscevo ogni singola riga nel codice sorgente => pieno controllo. Ma non consiglierei di usare quel framework a nessuno al di fuori del mio team / dei miei progetti.

Quando usi qualcosa del genere è importante sapere come viene implementato, ciò significa che dovresti dedicare molto tempo all'apprendimento della libreria / strumento. Se non hai tempo per impararlo, non usarlo. Anche se sembra molto facile dall'inizio.