Ho letto / guardato molti contenuti di Robert C. Martin. Mi sono imbattuto in lui dicendo che SQL non è necessario a causa delle unità a stato solido. Quando cerco altre fonti per eseguire il backup, ricevo un mucchio di articoli casuali che descrivono la differenza delle prestazioni SQL tra dischi rigidi e unità a stato solido (che è correlata ma non è ciò che sto cercando di ricercare).

Alla fine, non capisco a cosa stia cercando di arrivare. Sta dicendo sostituire SQL con le tecnologie No-SQL? Sta dicendo archiviare i dati in file in un file system? Oppure vuole semplicemente smettere di usare i database SQL / Relational a causa degli attacchi SQLi? Temo di perdere il punto che sta cercando di chiarire.

Fornirò alcuni link qui in modo che tu possa leggere direttamente dalla sua mente:

1. Tavoli Bobby
2. Conferenza sull'architettura pulita

Innanzitutto, afferma che SQL dovrebbe essere rimosso completamente dal sistema.

La soluzione. L'unica soluzione È eliminare completamente SQL dal sistema. Se non esiste un motore SQL, non possono esserci attacchi SQLi.

E anche se parla della sostituzione di SQL con un'API, NON penso che significhi mettere SQL dietro un'API a causa di quella citazione precedente e di ciò che dice prima nell'articolo.

I frame non gestiscono il problema; ...

Nota a margine: nel dire SQL, sono abbastanza sicuro che Robert significhi la maggior parte dei database relazionali. Forse non tutti ma soprattutto. In ogni caso, la maggior parte delle persone utilizza comunque SQL. così...

Se SQL non viene utilizzato per persistere nei dati, cosa dovremmo usare?

Prima di rispondere, dovrei anche notare. Robert sottolinea che le unità a stato solido dovrebbero cambiare gli strumenti che utilizziamo per mantenere i dati. La risposta di Søren D. Ptæus lo sottolinea.

Devo anche rispondere al gruppo "ma integrità dei dati". Su alcune ulteriori ricerche, Robert afferma che dovremmo usare database transazionali come Datomic . Quindi CRUD si trasforma in CR (crea e leggi) e le transazioni SQL scompaiono del tutto. L'integrità dei dati è ovviamente importante.

Non riesco a trovare una domanda che racchiuda tutto questo. Immagino che sto cercando alternative che corrispondano alle linee guida di Robert. Datomic è uno ma è quello? Quali altre opzioni corrispondono a queste linee guida? E funzionano davvero meglio con le unità a stato solido?

Bob Martin sta chiaramente esagerando per rendere più chiaro il suo punto. Ma qual è il suo punto?

Vuole solo che le persone smettano di usare i database SQL / Relational a causa degli attacchi SQLi?

Per quanto ne so, in quel post sul blog (il tuo primo link) Martin cerca di convincere le persone a smettere di usare SQL, ma non i database relazionali. Queste sono due cose diverse .

SQL è un linguaggio estremamente potente ed è standardizzato in una certa misura. Permette di creare query e comandi complessi in modo molto compatto, in modo leggibile, comprensibile, facile da imparare. Non dipende da un altro linguaggio di programmazione, quindi è utilizzabile per la maggior parte dei programmatori di applicazioni, indipendentemente dal fatto che preferiscano Java, C, C ++, C #, Python, Ruby, JavaScript, Basic, Go, Perl, PHP o qualcos'altro.

Tuttavia, questo potere ha un costo : scrivere query / comandi SQL sicuri è più difficile che scrivere quelli non sicuri. Un'API sicura dovrebbe facilitare la creazione di query sicure "per impostazione predefinita". Quelli potenzialmente non sicuri dovrebbero aver bisogno di più sforzi mentali o almeno più di battitura. Questo è l'IMHO per cui Martin sta sfidando SQL nella sua forma attuale.

Il problema non è nuovo e esistono API più sicure rispetto allo standard SQL per accedere a un database relazionale. Ad esempio, tutti i mappatori OR che conosco stanno cercando di fornire tale API (anche se in genere sono progettati per altri obiettivi primari). Le varianti SQL statiche rendono difficile la creazione di query dinamiche con dati di input non dinamici (e non si tratta di una nuova invenzione: SQL incorporato, che utilizza spesso SQL statico, ha circa 30 anni).

Sfortunatamente, non sono a conoscenza di alcuna API flessibile, standardizzata, matura, indipendente dalla lingua e potente come SQL, in particolare SQL dinamico. Ecco perché ho qualche dubbio sul suggerimento di Martin di "non usare SQL" come un modo realistico di risolvere i problemi citati. Quindi leggi il suo articolo come un pensiero nella giusta direzione, non come una "best practice" che puoi seguire alla cieca da domani in poi.

L'opinione di Bob Martin è proprio questo; l'opinione di un uomo.

Un programmatore dovrebbe comprendere il sistema che sta scrivendo abbastanza bene da esercitare una ragionevole cura della sua sicurezza e delle sue prestazioni. Ciò significa che, se stai parlando con un database SQL, fai quello che dice il sito Web Bobby Tables : disinfetta i tuoi dati di input. Ciò significa che il database SQL viene inserito in un computer che promette prestazioni adeguate. Esistono modi molto noti e ben compresi per fare queste cose, e sebbene non garantiscano la sicurezza assoluta o le prestazioni ideali, nient'altro.

L'affermazione che non abbiamo più bisogno di SQL perché ora abbiamo SSD è solo speciosa. SQL non è stato inventato perché i dischi rigidi ad alta velocità non esistevano ancora; è stato inventato perché avevamo bisogno di un modo standard per esprimere concetti di recupero dei dati. I sistemi di database relazionali hanno molte altre qualità oltre alla velocità e alla sicurezza che li rendono ideali per le operazioni aziendali; in particolare, ACID . L'integrità dei dati è importante almeno quanto la velocità o la sicurezza e, se non li possiedi, qual è il punto di proteggere i dati errati o recuperarli il più rapidamente possibile?

Prima di prendere l'isteria di un uomo come vangelo, ti suggerisco di conoscere la sicurezza e le prestazioni dell'applicazione e del sistema alle loro condizioni, non leggendo articoli casuali su Internet. C'è molto di più in termini di sicurezza, prestazioni e progettazione di sistemi robusti oltre al semplice "evitare questa tecnologia".

Non vietiamo i coltelli da cucina perché alcuni sfortunati riescono a tagliarsi accidentalmente le dita con loro.

Cosa sta realmente dicendo?

Sta dicendo sostituire SQL con le tecnologie No-SQL?

TL; DR: Sì (sorta di)

In un discorso più recente di quello a cui ti sei collegato sostanzialmente sullo stesso argomento, dice: "Il database è un dettaglio. Perché abbiamo database?" .

Afferma che il database è nato per rendere più facile l'accesso ai dati dai dischi rotanti, ma in futuro "[...] non ci saranno dischi" grazie alla nuova tecnologia e a ciò che chiama "RAM persistente" e che sarà più facile memorizzare i dati utilizzando le strutture utilizzate dai programmatori, come hashtable o alberi.

Continua predicendo che i database relazionali nel loro insieme scompariranno in gran parte a causa della loro nuova concorrenza:

Se fossi Oracle, sarei piuttosto spaventato perché la ragione della mia esistenza sta evaporando da sotto di me. [...] La ragione per l'esistenza del database sta scomparendo.

Probabilmente ci saranno alcuni tavoli relazionali che sopravviveranno, ma ora c'è una sana competizione .

Quindi no, per lui non si tratta solo di SQL injection, anche se lui ritiene che SQL sia intrinsecamente imperfetto in questo senso .

Nota dell'autore:

Le dichiarazioni in questo post sono solo citazioni per comprendere l'opinione di Robert C. Martin su questo argomento e non rappresentano l'opinione dell'autore. Per un punto di vista più differenziato, vedi la risposta di Robert Harvey .

SQL è un dettaglio. La conoscenza di un dettaglio non dovrebbe diffondersi.

Man mano che SQL viene utilizzato in sempre più posizioni nel codice, il codice diventa sempre più dipendente da esso.

Man mano che apprendi sempre più trucchi SQL, risolvi sempre più problemi utilizzando SQL. Ciò significa che il passaggio a un'altra API per persistere implica molto di più della semplice traduzione. Devi risolvere problemi che non ti rendevi conto di avere.

Ti imbatti in questo passaggio anche tra i database. Uno offre la fantastica funzione whizzbang 5, quindi la usi in diversi punti solo per scoprire che la caratteristica whizzbang 5 è proprietaria e ora hai un problema di licenza che costerà un sacco di soldi. Quindi fai molto lavoro scavando ovunque hai usato la funzione 5 e risolvendo il problema da solo solo per scoprire in seguito che stai usando anche la funzione whizzbang 3.

Una delle cose che rende Java così portatile è che alcune funzionalità della CPU non sono disponibili. Se fossero disponibili li userei. E improvvisamente ci sono CPU su cui il mio codice Java non funzionerà perché non hanno quelle funzionalità. È lo stesso con le funzionalità del database.

È facile sacrificare la tua indipendenza senza accorgertene. SQL è una scelta non un dato. Se decidi di usare SQL, fallo in un unico posto. Fallo in un modo che può essere disfatto.

Il fatto che SQL abbia problemi di sicurezza e che stiamo passando a modelli di memoria persistenti non significa che SQL sia condannato. Porta a casa il punto in cui è una scelta. Se vuoi preservare il diritto di fare quella scelta devi fare il lavoro.

Vale la pena notare che il movimento di database degli anni '80 e lo zio Bob hanno una storia piuttosto brutta. Ha avuto tutti i suoi problemi risolti con un file system semplice quando la gestione ha costretto un amministratore di database nella sua vita. Questo evento lo ha spinto nella sua carriera di consulenza stellare. (Racconta questa storia in uno dei suoi primi libri chiari, dimentica quale) Sa come risolvere i problemi senza DB e ha poca pazienza per coloro che si comportano come se li usassero è un dato di fatto.

Racconta anche una storia su come rimandare l'aggiunta di un DB a un'applicazione fino all'ultimo minuto quando un cliente lo ha richiesto e lo ha aggiunto in un giorno come funzionalità opzionale. La mia ipotesi è che vede come la maggior parte di noi usa i DB come dipendenza. Sta cercando di mostrarci come liberarci dall'abitudine.

La citazione dalla tua prima citazione è (enfasi mia),

La soluzione. L'unica soluzione È eliminare completamente SQL dal sistema . Se non esiste un motore SQL, non possono esserci attacchi SQLi.

Cosa sostituirebbe SQL? Un'API ovviamente! E NON un'API che utilizza un linguaggio testuale. Invece, un'API che utilizza un set appropriato di strutture dati e chiamate di funzioni per accedere ai dati necessari.

Il rant è contrario a consentire ai programmatori di applicazioni di utilizzare SQL.

La soluzione suggerita è quella di consentire loro di utilizzare invece un'API: che non è SQL e non consente l'iniezione.

IMO, esempi di tali API potrebbero includere:

• http://bobby-tables.com/csharp suggerisce che i programmatori C # possono usare l'API ADO.NET.

  Questo non è un esempio perfetto perché ADO.NET è un'API ampia o profonda (ovvero potente o generica), che consente anche ai suoi utenti di inserire SQL raw (o raw-ish).

• Alcuni sviluppatori SQL o amministratori di database suggeriscono che un database dovrebbe essere configurato in modo tale da consentire l'accesso solo tramite (un numero limitato di procedure memorizzate per iscritto) e che agli sviluppatori di applicazioni non dovrebbe essere consentito di scrivere le proprie (pericolose) query SQL

• Un altro modo per "eliminare SQL dal sistema" è di mettere il database (che espone SQL) su qualche altro sistema, a cui si accede tramite un'API REST o simile.

Quindi, IMO, la soluzione globale o i sistemi possono ancora usare un database (specialmente dato che un motore di database implementa utili proprietà ACID, si ridimensiona bene e così via, potrebbe essere sciocco provare a fare a meno di uno o scrivere uno specifico per l'applicazione).

I requisiti del rant sono soddisfatti se l'API SQL del database è nascosta agli sviluppatori dell'applicazione, dietro qualche altra API (ad esempio ADO, forse un ORM, un servizio Web o altro).

Più in generale suppongo significhi avere un DAL specifico per l'applicazione (un "livello di accesso ai dati" o "livello di astrazione del database"). Un DAL isola l'applicazione dai dettagli di come e dove i dati vengono archiviati e / o recuperati. Il DAL può o non può essere implementato utilizzando un database SQL.

Tutti sembrano rispondere a questa domanda dal punto di vista della sicurezza o con un obiettivo SQL.

Ho visto una lezione di Robert Martin in cui racconta che come programmatori, usiamo molte diverse strutture di dati che sono ottimali per i nostri programmi specifici. Pertanto, anziché archiviare universalmente tutti i dati in una struttura tabulare, dovremmo archiviare i nostri dati in tabelle hash, alberi, ecc. In modo da poter acquisire i dati e passare direttamente al programma.

Ho interpretato il suo messaggio come solo dicendo che dovremmo eliminare per un momento le nostre attuali ipotesi sull'archiviazione persistente per considerare altre possibilità future oltre all'antico formato tabulare SQL. SSD è una soluzione candidata, ma non l'unica.

In realtà, non deve usare database e SQL - in modo abbastanza esplicito. Il primo riferimento è un problema ben noto, il secondo riferimento viene fuori suonando come un rant. Anche se lo sto interpretando come un buon motivo per usare i database e non usare SQL. Dal mio punto di vista, questo non è nemmeno un consiglio ragionevole.

Sfortunatamente, l'esempio che sta usando è un esempio ben noto con una soluzione ben nota che poi sottolinea. Di solito si verifica quando un programmatore non si rende conto di ciò che sta facendo. Ad esempio la costruzione di stringhe contenenti SQL come:

    my $sql="select a from b where a=$ui_val;";
    prepare($sql)
    execute($sql)

al contrario di

    my $sql="select a from b where a=?;";
    prepare($sql)
    execute($sql,$ui_val);

Questo è un DBI perl come esempio per il codice ruby ​​on rails. Il codice delle rotaie che fornisce è facile da confondere tra il sicuro e il non sicuro. Come molti ORM nasconde ciò che è sotto l'SQL e così spesso hai a che fare con un'interfaccia che costruisce ed esegue sql per te. Non sembra quasi quello che un'API farebbe per te?

La mia interpretazione del primo riferimento è che sta suggerendo che dovremmo sostituire un problema ben noto che ha una soluzione ben nota.

È anche un peccato che non menzioni che se fatto correttamente renderà il codice più facile da scrivere e più leggibile, sebbene se fatto bene, potrebbe effettivamente essere più difficile da scrivere e meno leggibile. Inoltre, non menziona il fatto che SQL è davvero molto facile da leggere e fa quello che generalmente ti aspetteresti.

È parzialmente corretto, alla fine avremo una memoria infinitamente grande e veloce e un processore infinitamente veloce. Fino a quando non usciremo dalla fisica attuale che limita il calcolo, non è corretto.

Sì, i dischi rotanti appartengono al passato e ora utilizziamo SSD. I dischi funzionano con circa ~ 10 millisecondi per trasferimento di dati, gli SSD funzionano con ~ 0,5 millisecondi (500 microsec) di tempo di accesso ai dati. La RAM è nell'ordine di 100 nano secondi, i processori funzionano su 100 secondi di pico secondi. Questo è il cuore del motivo per cui abbiamo bisogno di database. I database gestiscono il trasferimento di dati tra dischi rotanti o SSD con memoria principale. L'avvento degli SSD non ha eliminato la necessità di database.

Risposta

vuole solo che le persone smettano di usare i database SQL / Relational a causa degli attacchi SQLi?

L'articolo "Tabelle Bobby" sembra suggerire che questo, di per sé, è un motivo per non usare SQL:

La soluzione. L'unica soluzione È eliminare completamente SQL dal sistema. Se non esiste un motore SQL, non possono esserci attacchi SQLi.

Potrebbe avere altre ragioni di cui parla altrove. Non lo saprei perché non leggo molto della sua roba.

Digressione

Questa parte non è in realtà una risposta, ma penso che la domanda sul valore di SQL sia molto più interessante (come fanno gli altri, a quanto pare).

Ho avuto molta esperienza nell'uso di SQL e penso di avere una buona comprensione dei suoi punti di forza e di debolezza. La mia sensazione personale è che è stato abusato e abusato, ma l'idea che non dovremmo mai usarlo è un po 'sciocca. L'idea che dobbiamo scegliere "SQL always" o "SQL never" è una falsa dicotomia.

Per quanto l'iniezione di SQL sia un argomento per non usare SQL, è ridicolo. Questo è un problema ben compreso con una soluzione piuttosto semplice. Il problema con questo argomento è che SQLi non è l'unica vulnerabilità esistente. Se ritieni che l'utilizzo delle API JSON ti renda sicuro, avrai una grande sorpresa.

Penso che ogni sviluppatore dovrebbe guardare questo video dal titolo "Venerdì 13: Attacking JSON - Alvaro Muñoz & Oleksandr Mirosh - AppSecUSA 2017"

Se non hai il tempo o la propensione a controllarlo, ecco l'essenza: molte librerie di deserializzazione JSON hanno vulnerabilità legate all'esecuzione di codice in modalità remota. Se stai usando XML, devi preoccuparti ancora di più. Il divieto di SQL dalla tua architettura non renderà sicuro il tuo sistema.

Voglio affrontare solo una breve dichiarazione:

Oppure vuole semplicemente smettere di usare i database SQL / Relational a causa degli attacchi SQLi?

No. Questa è un'ipotesi sbagliata. Non possiamo dire che dobbiamo smettere di usare le auto, perché sono responsabili delle persone che muoiono in incidenti stradali. Allo stesso modo, i database SQL / relazionali (o qualsiasi altra cosa in questo contesto, come RDBMS) non sono responsabili del payload SQL dannoso che un utente malintenzionato può eseguire sull'applicazione Web. Sono sicuro che l'autore non intendeva questo, perché a questo scopo esiste un intero cheat sheet sulla prevenzione dell'iniezione SQL .

Il problema di Martin sembra essere con i programmatori che creano SQL dinamico direttamente dall'input dell'utente, qualcosa del tipo (perdonami, sono principalmente un programmatore C e C ++):

sprintf( query, "select foo from bar where %s;", user_input );

che è assolutamente una ricetta per il bruciore di stomaco (da qui la striscia di Bobby Tables ). Qualsiasi programmatore che inserisce codice del genere in un sistema di produzione merita un paddlin '.

È possibile mitigare (se non eliminare del tutto) il problema utilizzando istruzioni preparate e disinfettando correttamente i dati immessi. Se riesci a nascondere l'SQL dietro un'API in modo tale che i programmatori non stiano costruendo direttamente stringhe di query, tanto meglio (che fa parte di ciò che sostiene Martin).

Ma per quanto riguarda eliminare completamente SQL, non penso che sia pratico o desiderabile. I modelli relazionali sono utili , ecco perché esistono in primo luogo e SQL è probabilmente la migliore interfaccia per lavorare con i modelli relazionali.

Come sempre, si tratta di utilizzare lo strumento giusto per il lavoro. Se l'app del carrello non necessita di un modello relazionale completo, non utilizzare un modello relazionale (ciò significa che non sarà necessario utilizzare SQL). Per le volte in cui hai bisogno di un modello relazionale, allora quasi sicuramente lavorerai con SQL.

Le due fonti che colleghi trasmettono messaggi diversi:

Il post sul blog afferma che la logica di accesso ai dati non dovrebbe esistere come testo in fase di esecuzione, per timore che non sia mescolata con input dell'utente non attendibile. Cioè, il post sul blog condanna la scrittura di query concatenando stringhe.

La lezione è diversa. La prima differenza è nel tono: la lezione specula e mette in discussione, ma non condanna. Non dice che i database sono cattivi, ma ci sfida a immaginare la persistenza senza un database. Sostiene che nei 30 anni trascorsi dalla diffusione dei database relazionali molte cose sono cambiate, e ne evidenzia due che potrebbero influenzare la nostra scelta di tecnologia di persistenza:

• lo spazio di archiviazione è aumentato di un fattore di circa 1 milione - a prezzi comparabili! Di conseguenza, è meno necessario conservare l'archiviazione e, in particolare, non è più necessario eliminarlo. Utilizzando l'archiviazione solo append, il controllo della concorrenza può essere semplificato perché i blocchi di lettura non sono necessari. Ciò può ovviare alla necessità di transazioni.
• i tempi di accesso sono diminuiti, poiché la maggior parte dei set di dati ora si inserisce nella RAM, riducendo notevolmente la latenza di lettura.

Queste mutate circostanze cambiano la tecnologia di persistenza ottimale? È interessante notare che lo zio Bob non dice - presumibilmente perché non ritiene che una risposta sia corretta per tutti i programmi. Ecco perché ci mette in guardia nel considerare la nostra scelta della tecnologia di persistenza come un dettaglio piuttosto che incorporarla in tavolette di pietra e trasmetterla come saggezza ricevuta ai nostri pari.

Esistono alternative?

La scrittura della logica di accesso ai dati senza stringhe è del tutto possibile. In Java land, è possibile utilizzare QueryDSL , in cui le query sono descritte utilizzando un'API fluida di tipo sicuro generata dallo schema del database. Tale query potrebbe apparire come segue:

JPAQuery<?> query = new JPAQuery<Void>(entityManager);
Customer bob = query.select(customer)
  .from(customer)
  .where(customer.firstName.eq("Bob"))
  .fetchOne();

Come puoi vedere, la logica della query non è espressa come una stringa, separando chiaramente la struttura attendibile della query dai parametri non attendibili (e, naturalmente, QueryDSL non include mai i parametri nel testo della query, ma utilizza istruzioni preparate per separare la query per i suoi parametri a livello JDBC). Per ottenere l'iniezione SQL con QueryDSL, dovresti scrivere il tuo parser per analizzare una stringa e tradurla in un albero di sintassi e, anche se lo facessi, probabilmente non aggiungeresti supporto per cose brutte come select ... into file. In breve, QueryDSL rende praticamente impossibile l'iniezione di SQL e migliora anche la produttività del programmatore e aumenta la sicurezza del refactoring. Impedito il maggior rischio per la sicurezza delle applicazioni Web, che esiste da abbastanza tempo per generare gag in esecuzionee aumentato la produttività degli sviluppatori? Oserei dire che se scrivi ancora query come stringhe, stai sbagliando.

Per quanto riguarda le alternative alle basi di dati relazionali, è curioso sapere che il controllo della concorrenza multi versione di postgres è esattamente quel tipo di struttura di dati di sola aggiunta di cui parla lo zio Bob, anche se probabilmente stava pensando di più agli archivi di eventi e al reperimento di eventi modello in generale, che si adatta bene anche all'idea di mantenere lo stato corrente nella RAM.