Perché nessun amore per SQL? [chiuso]

Ultimamente ho sentito molto che SQL è un linguaggio terribile e sembra che ogni framework sotto il sole sia preconfezionato con un livello di astrazione del database.

Nella mia esperienza, tuttavia, SQL è spesso il modo molto più semplice, versatile e intuitivo per gestire l'input e l'output dei dati. Ogni livello di astrazione che ho usato sembra essere un approccio notevolmente limitato senza alcun vantaggio reale.

Cosa rende SQL così terribile e perché i livelli di astrazione del database sono preziosi?

Questo è in parte soggettivo. Quindi questa è la mia opinione:

SQL ha uno stile di linguaggio pseudo-naturale . Gli inventori credevano di poter creare una lingua proprio come l'inglese e che le query sul database sarebbero state molto semplici. Un terribile errore. SQL è molto difficile da capire tranne che in casi banali.

SQL è dichiarativo. Non puoi dire al database come dovrebbe fare le cose, solo quello che vuoi come risultato. Sarebbe perfetto e molto potente, se non dovessi preoccuparti delle prestazioni. Quindi finisci per scrivere SQL - leggere i piani di esecuzione - riformulare SQL cercando di influenzare il piano di esecuzione e ti chiedi perché non puoi scrivere il piano di esecuzione da solo .

Un altro problema del linguaggio dichiarativo è che alcuni problemi sono più facili da risolvere in modo imperativo. Quindi lo scrivi in ​​un'altra lingua (avrai bisogno di SQL standard e probabilmente un livello di accesso ai dati) o utilizzando estensioni linguistiche specifiche del fornitore, ad esempio scrivendo procedure memorizzate e simili. In questo modo probabilmente scoprirai che stai usando una delle peggiori lingue che tu abbia mai visto, perché non è mai stata progettata per essere usata come lingua imperativa.

SQL è molto vecchio . SQL è stato standardizzato, ma troppo tardi molti fornitori hanno già sviluppato le proprie estensioni linguistiche. Quindi SQL è finito in dozzine di dialetti. Ecco perché le applicazioni non sono portabili e un motivo per avere un livello di astrazione DB.

Ma è vero: non ci sono alternative praticabili. Quindi useremo tutti SQL per i prossimi anni.

A parte tutto ciò che è stato detto, una tecnologia non deve essere negativa per rendere prezioso uno strato di astrazione .

Se stai facendo uno script o un'applicazione molto semplice, puoi permetterti di mescolare le chiamate SQL nel tuo codice ovunque tu voglia. Tuttavia, se stai facendo un sistema complesso, isolare le chiamate al database in moduli separati è una buona pratica e quindi isolare il tuo codice SQL. Migliora la leggibilità, la manutenibilità e la testabilità del codice. Ti consente di adattare rapidamente il tuo sistema ai cambiamenti nel modello di database senza rompere tutte le cose di alto livello, ecc.

SQL è fantastico. Gli strati di astrazione sopra lo rendono ancora più grande!

Un punto degli strati di astrazione è il fatto che le implementazioni SQL tendono ad essere più o meno incompatibili tra loro poiché lo standard è leggermente ambiguo e anche perché la maggior parte dei fornitori ha aggiunto i propri extra (non standard) lì. Cioè, l'SQL scritto per un database MySQL potrebbe non funzionare in modo simile, ad esempio, con un database Oracle, anche se "dovrebbe".

Sono d'accordo, tuttavia, che SQL è molto migliore della maggior parte dei livelli di astrazione disponibili. Non è colpa di SQL se viene utilizzato per cose per cui non è stato progettato.

SQL viene diffamato da diverse fonti:

• Programmatori che non si sentono a proprio agio con nient'altro che un linguaggio imperativo.
• Consulenti che hanno a che fare quotidianamente con molti prodotti basati su SQL incompatibili
• Fornitori di database non relazionali che cercano di rompere la morsa dei fornitori di database relazionali sul mercato
• Esperti di database relazionali come Chris Date che considerano le attuali implementazioni di SQL insufficienti

Se ti attieni a un prodotto DBMS, sono assolutamente d'accordo sul fatto che i DB SQL sono più versatili e di qualità superiore rispetto alla concorrenza, almeno fino a quando non si incontra una barriera di scalabilità intrinseca nel modello. Ma stai davvero cercando di scrivere il prossimo Twitter o stai solo cercando di mantenere alcuni dati contabili organizzati e coerenti?

La critica dell'SQL è spesso un sostituto per le critiche agli RDBMS. Ciò che i critici degli RDBMS sembrano non capire è che risolvono abbastanza bene un'enorme classe di problemi informatici e che sono qui per rendere le nostre vite più facili, non più difficili.

Se fossero seriamente intenzionati a criticare SQL stesso, sosterrebbero sforzi come Tutorial D e Dataphor.

Non è così terribile. È una sfortunata tendenza in questo settore spazzare via la precedente tecnologia affidabile quando viene fuori un nuovo "paradigma". Alla fine della giornata, molto probabilmente questi framework utilizzano SQL per comunicare con il database, quindi come può essere COSÌ sbagliato? Detto questo, avere un livello di astrazione "standard" significa che uno sviluppatore può concentrarsi sul codice dell'applicazione e non sul codice SQL. Senza un tale livello standard probabilmente ne scriveresti uno leggero ogni volta che sviluppi un sistema, il che è uno spreco di fatica.

SQL è progettato per la gestione e l'interrogazione di dati basati su SET. Viene spesso utilizzato per fare di più e i casi limite a volte portano a frustrazione.

L'USO effettivo di SQL può essere così influenzato dal design del database di base che l'SQL potrebbe non essere il problema, ma il design potrebbe - e quando si inserisce il codice legacy associato a un cattivo design, le modifiche sono più impattive e costose da implementare ( a nessuno piace tornare indietro e "aggiustare" cose che "funzionano" e raggiungono gli obiettivi)

I falegnami possono battere chiodi con martelli, segare legname con seghe e assi lisce con pialle. È possibile "segare" usando martelli e pialle, ma è frustrante.

Non dico che è terribile. Non è adatto per alcune attività. Ad esempio: non è possibile scrivere un buon codice procedurale con SQL. Una volta sono stato costretto a lavorare con la manipolazione dei set con SQL. Mi ci è voluto un intero fine settimana per capirlo.

SQL è stato progettato per l'algebra relazionale: è lì che dovrebbe essere utilizzato.

Ultimamente ho sentito molto che SQL è un linguaggio terribile e sembra che ogni framework sotto il sole sia preconfezionato con un livello di astrazione del database.

Nota che questi livelli convertono semplicemente le loro cose in SQL. Per la maggior parte dei fornitori di database SQLè l'unico modo per comunicare con il motore.

Nella mia esperienza, tuttavia, SQL è spesso il modo molto più semplice, versatile e intuitivo per gestire l'input e l'output dei dati. Ogni livello di astrazione che ho usato sembra essere un approccio notevolmente limitato senza alcun vantaggio reale.

... motivo per il quale ho appena descritto sopra.

I livelli del database non aggiungono nulla, ti limitano . Rendono le query discutibilmente più semplici ma mai più efficienti.

Per definizione, non c'è nulla nei livelli del database che non sia presente SQL.

Cosa rende SQLcosì terribile e perché i livelli di astrazione del database sono preziosi?

SQL è un bel linguaggio, tuttavia, ci vuole un po 'di stravolgimento del cervello per lavorarci.

In teoria, SQL è dichiarativo, cioè dichiari ciò che vuoi ottenere e il motore lo fornisce nel modo più veloce possibile.

In pratica, ci sono molti modi per formulare una query corretta (ovvero la query che restituisce risultati corretti).

Gli ottimizzatori sono in grado di costruire un castello Lego con alcuni algoritmi predefiniti (sì, sono multipli), ma semplicemente non possono creare nuovi algoritmi. Ci vuole ancora un fileSQL sviluppatore per assisterli.

Tuttavia, alcune persone si aspettano che l'ottimizzatore produca "il miglior piano possibile", non "il miglior piano disponibile per questa query con una data implementazione del SQL motore".

E come tutti sappiamo, quando il programma per computer non soddisfa le aspettative delle persone, è il programma che viene incolpato, non le aspettative.

Nella maggior parte dei casi, tuttavia, riformulare una query può produrre effettivamente il miglior piano possibile. Ci sono attività in cui è impossibile, tuttavia, con i nuovi e crescenti miglioramenti aSQL questi casi diventano sempre meno numerosi.

Sarebbe bello, tuttavia, se i fornitori fornissero un accesso di basso livello a funzioni come "ottieni l'intervallo di indice", "ottieni una riga per rowid" ecc., ComeC compilatori ti permettessero di incorporare l'assembly direttamente nel linguaggio.

Recentemente ho scritto un articolo su questo nel mio blog:

• Doppio pensiero in SQL

Sono un grande sostenitore di ORM e credo ancora che SQL sia molto utile, anche se è certamente possibile farci cose terribili (proprio come qualsiasi altra cosa). .

Considero SQL un linguaggio super efficiente che non ha come priorità il riutilizzo del codice o la manutenibilità / refactoring.

Quindi l'elaborazione velocissima è la priorità. E questo è accettabile. Devi solo essere consapevole dei compromessi, che per me sono considerevoli.

Da un punto di vista estetico, come linguaggio sento che mancano alcune cose dato che non ha concetti OO e così via - mi sembra un codice procedurale molto vecchia scuola. Ma è di gran lunga il modo più veloce per fare certe cose, e questa è una nicchia potente!

Direi che un livello di astrazione del database incluso in un framework è una buona cosa perché risolve due problemi molto importanti:

1. Mantiene il codice distinto. Mettendo l'SQL in un altro livello, che generalmente è molto sottile e dovrebbe fare solo le basi dell'interrogazione e del trasferimento dei risultati (in modo standardizzato), mantieni la tua applicazione libera dal disordine di SQL. È lo stesso motivo per cui gli sviluppatori web (dovrebbero) inserire CSS e Javascript in file separati. Se puoi evitarlo, non mischiare le tue lingue .

2. Molti programmatori sono semplicemente pessimi nell'usare SQL. Per qualsiasi motivo, un gran numero di sviluppatori (specialmente sviluppatori web) sembra essere molto, molto cattivo nell'usare SQL o RDBMS in generale. Trattano il database (e SQL per estensione) come il piccolo intermediario sporco che devono attraversare per accedere ai dati. Ciò porta a database estremamente mal concepiti senza indici, tabelle impilate sopra tabelle in modi dubbi e query scritte molto male. O peggio, cercano di essere troppo generici (Expert System, chiunque?) E non possono ragionevolmente correlare i dati in modo significativo.

Sfortunatamente, a volte il modo in cui qualcuno cerca di risolvere un problema e gli strumenti che usa, a causa dell'ignoranza, della testardaggine o di qualche altro tratto, sono in diretta opposizione l'uno con l'altro, e buona fortuna cerca di convincerli di questo. In quanto tale, oltre ad essere solo una buona pratica, considero un livello di astrazione del database una sorta di rete di sicurezza, poiché non solo mantiene l'SQL fuori dagli occhi del povero sviluppatore, ma rende il loro codice significativamente più facile da refactoring, poiché tutte le query sono in un unico posto.

SQL è eccellente per alcuni tipi di attività, in particolare la manipolazione e il recupero di set di dati.

Tuttavia, SQL manca (o implementa solo parzialmente) diversi strumenti importanti per la gestione del cambiamento e della complessità:

• Incapsulamento : i meccanismi di incapsulamento di SQL sono grossolani. Quando scrivi codice SQL, devi sapere tutto sull'implementazione dei tuoi dati. Questo limita la quantità di astrazione che puoi ottenere.

• Polimorfismo : se vuoi eseguire la stessa operazione su tabelle diverse, devi scrivere il codice due volte. (Si può mitigare questo problema con un uso fantasioso delle viste.)

• Controllo della visibilità : non esiste un meccanismo SQL standard per nascondere parti del codice l'una dall'altra o raggrupparle in unità logiche, quindi ogni tabella, procedura, ecc. È accessibile da tutte le altre, anche quando non è desiderabile.

• Modularità e controllo delle versioni

Infine, la codifica manuale delle operazioni CRUD in SQL (e la scrittura del codice per collegarla al resto dell'applicazione) è ripetitiva e soggetta a errori.

Un moderno livello di astrazione fornisce tutte queste funzionalità e ci consente di utilizzare SQL dove è più efficace, nascondendo i dettagli di implementazione dirompenti e ripetitivi. Fornisce strumenti per aiutare a superare il disadattamento di impedenza relazionale oggetto che complica l'accesso ai dati nello sviluppo di software orientato agli oggetti.

SQL si basa sulla teoria degli insiemi, mentre la maggior parte dei linguaggi di alto livello sono orientati agli oggetti oggigiorno. I programmatori di oggetti in genere amano pensare per oggetti e devono fare un cambiamento mentale per utilizzare strumenti basati su Set per memorizzare i loro oggetti. In generale, è molto più naturale (per il programmatore OO) tagliare il codice nella lingua che preferisce e fare qualcosa come object.save o object.delete nel codice dell'applicazione invece di dover scrivere query sql e chiamare il database per ottenere lo stesso risultato.

Naturalmente, a volte per cose complesse, SQL è più facile da usare e più efficiente, quindi è bene avere un controllo su entrambi i tipi di tecnologia.

IMO, il problema che vedo che le persone hanno con SQL non ha nulla a che fare con la progettazione relazionale né con il linguaggio SQL stesso. Ha a che fare con la disciplina della modellazione del livello dati che per molti versi è fondamentalmente diversa dalla modellazione di un livello o interfaccia aziendale. Gli errori nella modellazione a livello di presentazione sono generalmente molto più facili da correggere che a livello di dati in cui sono presenti più applicazioni che utilizzano il database. Questi problemi sono gli stessi riscontrati nella modellazione di un livello di servizio nei progetti SOA in cui è necessario tenere conto degli attuali consumatori del servizio e dei contratti di input e output.

SQL è stato progettato per interagire con i modelli di database relazionali. Ci sono altri modelli di dati che esistono da tempo, ma la disciplina sulla progettazione del livello dati esiste correttamente indipendentemente dal modello teorico utilizzato e quindi, le difficoltà che gli sviluppatori hanno tipicamente con SQL sono solitamente legate ai tentativi di imporre un non relazionale modello di dati su un prodotto di database relazionale.

Per prima cosa, rendono banale l'uso di query parametrizzate, proteggendoti dagli attacchi di SQL injection. L'utilizzo di SQL grezzo, da questo punto di vista, è più rischioso, cioè più facile sbagliare dal punto di vista della sicurezza. Spesso presentano anche una prospettiva orientata agli oggetti sul tuo database, sollevandoti dal dover fare questa traduzione.

Hai sentito molto di recente? Spero che tu non confonda questo con il movimento NoSql. Per quanto ne so, si tratta principalmente di un gruppo di persone che utilizzano NoSql per app Web ad alta scalabilità e sembrano aver dimenticato che SQL è uno strumento efficace in uno scenario di "app Web ad alta scalabilità".

Il business del livello di astrazione consiste solo nel risolvere la differenza tra il codice orientato agli oggetti e il codice basato su set di tabelle come SQL ama parlare. Di solito questo si traduce nella scrittura di molte piastre della caldaia e di un codice di transizione opaco tra i due. ORM lo automatizza e quindi fa risparmiare tempo alle persone con obiettività aziendale.

Per i programmatori SQL esperti i lati negativi sono

• Verbosità
• Come molti hanno detto qui, SQL è dichiarativo, il che significa che l' ottimizzazione non è diretta . È come il rally rispetto alle corse su circuito.
• Framework che cercano di affrontare tutti i dialetti possibili e non supportano le scorciatoie di nessuno di essi
• Nessun facile controllo della versione.

Per altri, le ragioni sono quelle

• alcuni programmatori sono pessimi in SQL. Probabilmente perché SQL opera con insiemi, mentre i linguaggi di programmazione funzionano in paradigma di oggetti o funzionali. Pensare per insiemi (unione, prodotto, intersezione) è una questione di abitudine che alcune persone non hanno.
• alcune operazioni non sono autoesplicative: cioè all'inizio non è chiaro che dove e avere filtri diversi insiemi.
• ci sono troppi dialetti

L'obiettivo principale dei framework SQL è ridurre la digitazione. In qualche modo lo fanno, ma troppo spesso solo per domande molto semplici. Se provi a fare qualcosa di complesso, devi usare stringhe e digitare molto. I framework che cercano di gestire tutto il possibile, come SQL Alchemy, diventano troppo grandi, come un altro linguaggio di programmazione.

[aggiornamento del 26.06.10] Recentemente ho lavorato con il modulo ORM di Django . Questo è l'unico framework SQL degno che ho visto. E questo rende molto lavorare con le cose. Tuttavia, gli aggregati complessi sono un po 'più difficili.

SQL non è un linguaggio terribile, a volte non funziona molto bene con gli altri.

Se, ad esempio, hai un sistema che vuole rappresentare tutte le entità come oggetti in un linguaggio OO o in un altro, combinarlo con SQL senza alcun tipo di livello di astrazione può diventare piuttosto macchinoso. Non esiste un modo semplice per mappare una query SQL complessa nel mondo OO. Per allentare la tensione tra questi mondi vengono inseriti ulteriori strati di astrazione (un OR-Mapper per esempio).

SQL è un ottimo linguaggio per la manipolazione dei dati. Dal punto di vista dello sviluppatore, quello che non mi piace è che la modifica del database non interrompe il codice in fase di compilazione ... Quindi uso l'astrazione che aggiunge questa funzionalità al prezzo delle prestazioni e forse dell'espressività del linguaggio SQL , perché nella maggior parte delle applicazioni non è necessario tutto ciò che ha SQL.

L'altro motivo per cui SQL è odiato è a causa dei database relazionali.

Il teorema CAP diventa popolare:

Quali obiettivi potresti desiderare da un sistema di dati condivisi?

• Forte coerenza: tutti i client vedono la stessa vista, anche in presenza di aggiornamenti
• Alta disponibilità: tutti i client possono trovare qualche replica dei dati, anche in presenza di guasti
• Partition-tolerance: le proprietà del sistema rimangono valide anche quando il sistema è partizionato

Il teorema afferma che puoi sempre avere solo due delle tre proprietà CAP contemporaneamente

Indirizzo database relazionale Strong Consistency and Partition-Tolerance.

Quindi sempre più persone si rendono conto che il database relazionale non è il proiettile d'argento e sempre più persone iniziano a rifiutarlo a favore dell'alta disponibilità, perché l'alta disponibilità rende più facile il ridimensionamento orizzontale. Il ridimensionamento orizzontale guadagna popolarità perché abbiamo raggiunto il limite della legge di Moore , quindi il modo migliore per ridimensionare è aggiungere più macchine.

Se il database relazionale viene rifiutato, anche SQL viene rifiutato.

SQL ha molti difetti, come alcuni altri poster qui hanno sottolineato. Tuttavia, preferisco di gran lunga usare SQL su molti degli strumenti che le persone offrono come alternative, perché le "semplificazioni" sono spesso più complicate di quanto avrebbero dovuto semplificare.

La mia teoria è che SQL sia stato inventato da un gruppo di sciatori blu dalle torri d'avorio. L'intera struttura non procedurale. Sembra fantastico: dimmi cosa vuoi invece di come lo vuoi fare. Ma in pratica, spesso è più facile dare solo i passaggi. Spesso sembra che si provi a fornire istruzioni per la manutenzione dell'auto descrivendo le prestazioni dell'auto quando hai finito. Sì, potresti dire: "Voglio che l'auto raggiunga ancora una volta 30 miglia per gallone e funzioni con questo ronzio come questo ... hmmmm ... e, ecc." Ma non sarebbe più facile per tutti basta dire "Sostituisci le candele"? E anche quando si riesce a capire come esprimere una query complessa in termini non procedurali, il motore del database spesso presenta un piano di esecuzione molto inefficiente per arrivarci.

E la gestione dei null mi fa impazzire! Sì, in teoria deve essere suonato alla grande quando qualcuno ha detto: "Ehi, se null significa sconosciuto, l'aggiunta di un valore sconosciuto a un valore noto dovrebbe dare un valore sconosciuto. Dopo tutto, per definizione, non abbiamo idea di quale sia il valore sconosciuto ". Teoricamente, assolutamente vero. In pratica, se abbiamo 10.000 clienti e sappiamo esattamente quanti soldi ci devono 9.999 ma c'è qualche domanda sull'importo dovuto dall'ultimo e la direzione dice: "Qual è il totale dei nostri conti attivi?", Sì, il matematicamente corretto la risposta è "non lo so". Ma la risposta pratica è "calcoliamo $ 4,327,287,42 ma un conto è in questione quindi quel numero non è esatto". Sono sicuro che la direzione preferirebbe di gran lunga ottenere un numero vicino, se non certo, piuttosto che uno sguardo vuoto.

Detto questo, preferirei comunque usare SQL piuttosto che un livello costruito sopra SQL, che crea solo un altro intero set di cose che ho bisogno di imparare, e poi devo sapere che alla fine questo verrà tradotto in SQL, e talvolta Posso solo fidarmi che faccia la traduzione in modo corretto ed efficiente, ma quando le cose si complicano non posso, quindi ora devo conoscere il livello extra, devo ancora conoscere SQL e devo sapere come tradurrà posso ingannare il livello per indurre SQL a fare la cosa giusta. Arggh.

• Ogni fornitore estende la sintassi SQL per soddisfare le proprie esigenze. Quindi, a meno che tu non stia facendo cose abbastanza semplici, il tuo codice SQL non è portabile.

• La sintassi di SQL non è ortogonale; ad esempio, le select, insert, update,e deletedichiarazioni hanno tutti completamente differente struttura sintattica.

Sono d'accordo con i tuoi punti, ma per rispondere alla tua domanda, una cosa che rende SQL così "terribile" è la mancanza di completa standardizzazione di T-SQL tra i fornitori di database (Sql Server, Oracle ecc.), Il che rende improbabile che il codice SQL sia completamente portatile. I livelli di astrazione del database risolvono questo problema, sebbene con un costo in termini di prestazioni (a volte molto elevato).

Vivere con SQL puro può davvero essere un inferno di manutenzione. Per me il più grande vantaggio degli ORM è la capacità di refactoring sicuro del codice senza noiose procedure di "DB refactoring". Esistono buoni framework di unit test e strumenti di refactoring per i linguaggi OO, ma devo ancora vedere la controparte di Resharper per SQL, ad esempio.

Tuttavia, tutti i DAL hanno SQL dietro le quinte, e comunque devi conoscerlo per capire cosa sta succedendo al tuo database, ma lavorare quotidianamente con un buon livello di astrazione diventa più facile.

Se non hai usato troppo SQL, penso che il problema principale sia la mancanza di buoni strumenti per sviluppatori.

Se hai molta esperienza con SQL, prima o poi sarai frustrato dalla mancanza di controllo sul piano di esecuzione. Questo è un problema intrinseco nel modo in cui SQL è stato specificato ai fornitori. Penso che SQL debba diventare un linguaggio più robusto per sfruttare veramente la tecnologia sottostante (che è molto potente).

Veloce, scrivimi SQL per impaginare un set di dati che funziona in MySQL, Oracle, MSSQL, PostgreSQL e DB2.

Oh, giusto, l'SQL standard non definisce alcun operatore per limitare il numero di risultati che tornano e da quale riga iniziare.

Non c'è amore per SQL perché SQL è pessimo in termini di sintassi, semantica e utilizzo corrente. Spiegherò:

• la sua sintassi è una scheggia di cobol, tutte le critiche di cobol si applicano qui (in misura minore, per essere onesti). Cercare di essere un linguaggio naturale senza tentare effettivamente di interpretare il linguaggio naturale crea una sintassi arbitraria (è DROP TABLE o DROP, UPDATE TABLE, UPDATE o UPDATE IN, DELETE o DELETE FROM ...) e mostruosità sintattiche come SELECT (quante pagine fa si riempie?)
• anche la semantica è profondamente imperfetta, Date lo spiega in grande dettaglio, ma sarà sufficiente notare che una logica booleana a tre valori non si adatta davvero ad un'algebra relazionale in cui una riga può essere o non essere solo parte di una tabella
• avere un linguaggio di programmazione come interfaccia principale (e spesso unica) ai database si è rivelata una pessima scelta e ha creato una nuova categoria di difetti di sicurezza

Concordo con la maggior parte dei post qui sul fatto che il dibattito sull'utilità di SQL è per lo più soggettivo, ma penso che sia più soggettivo nella natura delle tue esigenze aziendali.

Le lingue dichiarative, come ha sottolineato Stefan Steinegger, sono utili per specificare cosa si vuole, non come si vuole farlo. Ciò significa che le tue varie implementazioni di SQL sono decenti da una prospettiva di alto livello: cioè, se tutto ciò che vuoi è ottenere alcuni dati e nient'altro conta, puoi soddisfarti scrivendo query relativamente semplici e scegliendo l'implementazione di SQL quello è giusto per te.

Se lavori a un livello molto "più basso" e hai bisogno di ottimizzare tutto da solo, è tutt'altro che ideale. L'uso di un ulteriore livello di astrazione può aiutare, ma se quello che stai veramente cercando di fare è specificare i metodi per l'ottimizzazione delle query e così via, è un po 'contro intuitivo aggiungere un intermediario quando cerchi di ottimizzare.

Il problema più grande che ho con SQL è come altri linguaggi "standardizzati", ci sono pochissimi standard reali. Preferirei quasi dover imparare un linguaggio completamente nuovo tra Sybase e MySQL in modo da non confondere le due convenzioni.

Sebbene SQL riesca a portare a termine il lavoro, ha sicuramente problemi ...

• cerca di essere contemporaneamente l'astrazione di alto e basso livello , e questo è ... strano. Forse avrebbero dovuto essere due o più standard a livelli diversi.
• è un enorme fallimento come standard . Molte cose vanno storte quando uno standard si mescola in tutto, chiede troppo di implementazioni, chiede troppo poco, o per qualche motivo non raggiunge l'obiettivo parzialmente sociale di motivare i fornitori e gli implementatori a produrre implementazioni interoperabili e rigorosamente conformi. Non si può certo dire che SQL abbia fatto nulla di tutto ciò. Guarda alcuni altri standard e nota che il successo o il fallimento dello standard è chiaramente un fattore dell'utile cooperazione raggiunta:
  • RS-232 ( cattivo , non abbastanza specificato, anche quale pin trasmette e quale pin riceve è opzionale, sheesh. Puoi conformarti ma comunque non ottenere nulla. Possibilità di interoperabilità di successo: davvero basse fino a quando il PC IBM non ha creato uno standard utile di fatto .)
  • IEEE 754-1985 Floating Point ( Bad , overreach: non un singolo supercomputer, workstation scientifica o microprocessore RISC lo ha mai adottato, sebbene alla fine dopo 20 anni siamo stati in grado di implementarlo bene in HW. Almeno il mondo alla fine è cresciuto in esso.)
  • C89, C99, PCI, USB, Java ( buono , standard o specifica, sono riusciti a motivare la stretta conformità da quasi tutti e tale conformità ha portato a un'interoperabilità di successo.)
• non è stato selezionato come probabilmente il database più importante del mondo . Anche se questo è più un datapoint che un motivo, il fatto che Google Bigtable non sia SQL e non sia relazionale è una sorta di anti-risultato per SQL.

Non mi piace SQL, ma non voglio nemmeno doverlo scrivere come parte di ciò che sto sviluppando. Il DAL non riguarda la velocità di commercializzazione - in realtà, non avrei mai pensato che ci sarebbe stata un'implementazione DAL più veloce delle query dirette dal codice. Ma l'obiettivo del DAL è astrarre . L'astrazione ha un costo, e qui è che ci vorrà più tempo per implementarla.

I vantaggi sono enormi, però. Scrittura di test nativi sul codice, utilizzo di classi espressive, set di dati fortemente tipizzati, ecc. Usiamo una sorta di "DAL", che è un'implementazione DDD pura che utilizza Generics in C #. Quindi abbiamo repository generici, implementazioni di unità di lavoro (transazioni basate su codice) e separazione logica. Possiamo fare cose come simulare i nostri set di dati con poco sforzo e svilupparli effettivamente prima delle implementazioni del database. C'era un costo iniziale nella costruzione di un simile quadro, ma è molto bello logica di business sia di nuovo la protagonista dello spettacolo. Consumiamo i dati come una risorsa ora e li trattiamo nella lingua che utilizziamo nativamente nel codice. Un ulteriore vantaggio di questo approccio è la netta separazione che fornisce. Ad esempio, non vedo più una query di database in una pagina Web. Sì, quella pagina ha bisogno di dati. Sì, il database è coinvolto. Ma ora, non importa da dove sto estraendo i dati, c'è un (e solo uno) posto dove entrare nel codice e trovarlo. Forse non è un grosso problema su progetti più piccoli, ma quando hai centinaia di pagine in un sito o dozzine di finestre in un'applicazione desktop, puoi davvero apprezzarlo.

In qualità di sviluppatore, sono stato assunto per implementare i requisiti dell'azienda utilizzando le mie capacità logiche e analitiche e la nostra implementazione del framework mi consente di essere più produttivo ora. In qualità di manager, preferirei che i miei sviluppatori usassero le loro capacità logiche e analitiche per risolvere i problemi piuttosto che scrivere SQL. Il fatto che possiamo costruire un'intera applicazione che utilizza il database senza avere il database fino a quando più vicino alla fine del ciclo di sviluppo è una bella cosa. Non è inteso come un colpo contro i professionisti del database. A volte l'implementazione di un database è più complessa della soluzione. SQL (e nel nostro caso, Views e Stored Procs, in particolare) sono un punto di astrazione in cui il codice può consumare i dati come servizio. Nei negozi dove esiste una netta separazione tra i dati e i team di sviluppo, questo aiuta ad eliminare la permanenza in uno schema di attesa in attesa dell'implementazione e delle modifiche del database. Gli sviluppatori possono concentrarsi sul dominio del problema senza passare il mouse su un DBA e il DBA può concentrarsi sulla corretta implementazione senza che uno sviluppatore ne abbia bisognoadesso .

Molti post qui sembrano sostenere che SQL è sbagliato perché non ha funzionalità di "ottimizzazione del codice" e che non si ha alcun controllo sui piani di esecuzione.

Ciò in cui sono bravi i motori SQL è elaborare un piano di esecuzione per un'istruzione scritta, orientata ai dati , ai contenuti effettivi . Se ti interessa dare uno sguardo oltre il lato della programmazione, vedrai che i dati sono più che byte passati tra i livelli dell'applicazione.