Astrazione del database: è eccessivo?

Question

Astrazione del database: è eccessivo?

#1 da (10 voti)
#2 da (9 voti)
#3 da (5 voti)
#4 da (4 voti)

18

Dopo essere stato esposto a numerosi livelli di astrazione del database, comincio a chiedermi quale sia il significato di ogni libreria che inventa il proprio paradigma per accedere ai dati. Raccogliere un nuovo DAL è come imparare una nuova lingua da capo, quando di solito tutto ciò che voglio fare è convincere il livello ad emettere 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 tale scopo. Forse sono solo io, ma capisco lo snippet C molto più facilmente dei primi due. Le parole chiave e gli accorgimenti di sintassi rinominati sono carini, ma IMO, quando arriva fino a questo punto, non rendono più facile il recupero delle righe per il coder.

Probabilmente è sembrato un lungo rant, ma qui è una vera domanda. Dal momento che ogni DAL sembra inventare una nuova DSL per le query piuttosto che analizzare solo SQL provato e true, è necessario che i vantaggi dell'uso della sintassi diversa o delle deficienze nella sintassi SQL standard di cui non mi rendo conto siano presenti. Qualcuno potrebbe per favore indicare cosa sto trascurando qui?

sql api-design database dsl

posta Note to self - think of a name 15.04.2011 - 21:21

fonte

4 risposte

Leggi altre domande sui tag sql api-design database dsl

Perché MVC è più popolare del PAC? [chiuso] Come proteggere al meglio da 0 passati ai parametri std :: string?

score 10 · Answer 1

Il problema più fondamentale dell'uso SQL comune è che le query SQL sono stringhe, che sono in qualche modo composte da un'altra lingua. Questo è il punto da cui provengono le iniezioni SQL e altre vulnerabilità e WTF (il tuo esempio è piuttosto scarsamente scelto, perché la tua query non ha alcun parametro).

Il prossimo problema è in realtà un corollario: se hai solo un codice SQL scritto nel tuo codice, il compilatore non può fare nulla al riguardo. Errori come errori di battitura nei nomi delle colonne verranno visualizzati solo in fase di esecuzione. Questo è fondamentalmente il motivo per cui non si desidera solo una rappresentazione stringa della query nel 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 associare un database relazionale alla semantica della lingua e al modello di programmazione: gli RDBMS non vanno bene insieme a OOP (o recupero dei dati di navigazione). In realtà, questa è una pessima idea che combina questi due, ma è ciò che sono tutti i DAL orientati agli oggetti per i database SQL (vale a dire gli ORM). Ma tutti questi strati di astrazione sono condannati a trapelare. Penso che questo sia fondamentalmente il motivo per cui ce ne sono così tanti: perché lavori con loro, vedi che sono imperfetti, ti metti a 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 immediata 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 quello che puoi fare è scegliere con cura alcuni e attenersi a loro.

score 9 · Answer 2

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

score 5 · Answer 3

Mi sembra che SQL stia sperimentando lo stesso grande cambiamento che i suggerimenti erano 10 anni fa. C'è un continuo tentativo di eliminare il lavoro manuale con SQL e portarlo a un livello di astrazione più alto. Lo stesso è successo con i puntatori e la gestione manuale della memoria molti anni fa.

Dato che 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 manifesti.

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 codice dell'applicazione.

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

score 4 · Answer 4

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 suggerirei di usare quella struttura per nessuno al di fuori del mio team / progetti.

Quando usi qualcosa del genere è importante sapere come è implementato, il che significa che devi dedicare molto tempo all'apprendimento della libreria / dello strumento. Se non hai tempo per impararlo - non usare. Anche se sembra molto facile dall'inizio.