Web Log di Raffaele Rialdi

# re: Il movimento NoSQL

Il post che hai segnalato è molto interessante per la panoramica che fa. Forse nella parte dei Database-as-a-Service mancano MS con Azure Table Storage visto che ha API REST utilizzabili anche senza mettere l'applicazione su Azure.
... imho :)

# re: Il movimento NoSQL

Ciao Fabrizio, l'avevo notato ma il discorso nella sua interezza cambia poco.

Tra l'altro su questo argomento non ho ancora letto nulla riguardo ai costi in termini di consumo CPU di Sql su azure in comparazione al table storage. Chissà, potrebbe essere un requisito vincolante in certi progetti ...

# re: Il movimento NoSQL

Dai Alessandro, non mi dire che allora dovremmo tutti usare SQL solo perché bene o male lo sanno fare tutti.
Prima di tutto non sono daccordo che veramente tutti quelli che usano un db lo sappiano fare, altrimenti tutti saprebbero cos'è SQL injection e invece puntualmente *ovunque* vada c'è sempre qualcuno che non lo sa.

E poi se lo strumento giusto è un altro e non lo sai usare ... cambia mestiere!!! :)

# re: Il movimento NoSQL

Semplicemente non sono daccordo. L'approccio classico presuppone comunque delle minime conoscenze che non sono diffuse così come si crede.`

Per quanto riguarda SQL Injection, siamo daccordo che non è colpa del linguaggio di per se, ma purtroppo quel tipo di approccio è prono a questo tipo di errori. Siccome non credo che mai si riuscirà a evincere tutti del problema e convincerli che concatenare le stringhe è sbagliato, è meglio trovare una soluzione che funzioni senza la collaborazione del dev che ignora le conseguenze. Questo però è un discorso che è totalmente indipendente dalla faccenda noSQL.

Ci sono tante cose che non mi vanno dell'approccio classico nei rdbms e non mi sembra di averne mai fatto un mistero o mitigato in alcun modo.
Non essere daccordo con certi approcci architetturali non significa fare guerre di religione che respingo totalmente. Io semplicemente appoggio le mie idee e lascio liberi gli altri di fare altrettanto.
Per quanto riguarda le sp_executesql ricordi male. Il mio discorso riguardava l'inutilità, per quanto riguarda le performance, di usare le sp quando poi dentro ci trovi sp_executesql e 'scopri' che il numero di ricompilazioni al secondo va alle stelle nel perfmon. Ho quindi voluto sfatare un falso mito molto diffuso per cui se scrivo una sp è certamente più performante.

E poi non capisco perché questo rivangare di faccende sulle stored procedure. Non capisco soprattutto perché ogni volta che parlo di questi temi qualcuno sente la scossa come fosse dal dentista. Qui sembri più tu a iniziare l'ennesima guerra di religione.

E tornando al topic iniziale trovo semplicemente assurdo liquidare una alternativa solo perché bisogna studiarla. Se l'umanità avesse avuto questo atteggiamento saremmo ancora alle caverne.

# re: Il movimento NoSQL

Vabbe', facciamo quelli che non si capiscono, con tu che continui a bollare come pelandroni e diciamo pure scarsi, quelli che non si fanno almeno un 12 ore/giorno per 7 giorni la settimana sopra l'IT, ok no problem, comunque ribadisco che:

"utilizzare la migliore strategia a seconda del contesto in cui si sviluppa"

Non è una soluzione così ovvia e concretamente praticabile, infatti parafrasandoti, se l'umanità lo avesse fatto in modo maggiormente (ma di parecchio eh) capillare, ora saremmo in un mondo molto ma molto migliore, garantito.

# re: Il movimento NoSQL

Mi spiace, ma non mi considero polemico e men che meno poco ottimista, ma semplicemente realista.
Dal fare 2 prove e qualche demo con una tecnologia ed usarla efficacentemente in produzione ci passa un'enorme differenza, soprattutto nel contesto a cui ci si vuole riferire con questo post di Raf.
Non capisco, per esempio, che difficoltà ci sia nel capire che chi scrive codice che soffre di sql injection, scriverà ovviamente del codice con altre tecnologie che soffrirà dei problemi legati a quella tecnologia, mi pare ovvio (non è un esempio a caso visto che il nome del "movimento" noSQL mi pare abbastanza chiaro...), e più il contesto è delicato e complesso, più i castroni saranno determinanti.
E per conoscere bene una tecnologia per usarla in modo efficente in produzione ci vuole tempo, bel tempo, e certo, più uno è capace e meno tempo ci vuole (complice anche il fatto che la tecnologia nel frattempo matura), ma, di nuovo, questo non può essere un dettaglio trascurabile quando si devere creare una soluzione ad un problema e non solo fare qualche prova per gusto personale.

Investire qualche ora per studiare una tecnologia alternativa basterà si e no al 5% di chi lavora nell'IT per poi decidere di usarla in produzione senza andare a gambe all'aria, peccato quindi che il 95% di chi lavora nell'IT non sia in grado di seguire questo pattern, e visto che i dindi sono mossi da questa maggioranza, mi pare chiaro quello che volevo dire fin dall'inizio con:
"
"utilizzare la migliore strategia a seconda del contesto in cui si sviluppa"

Non è una soluzione così ovvia e concretamente praticabile
"

# re: Il movimento NoSQL

La differenza tra SQL Injection e, ad esempio, far schiantare l'applicazione per non aver usato un try/catch è bella grossa.
SQL Injection ad oggi è la vulnerabilità numero 1 su internet, si parla di compromettere dei dati e il problema è più difficilmente misurabile rispetto alla applicazione che si schianta dal cliente.
La colpa in entrambi i casi è del dev, ma stai sicuro che curerà di più lo schianto della sql injection, perché questa il cliente non la vede nella finestra.
Insomma un conto è cadere dalla sedia e un'altro è precipitare da una montagna.

Io semplicemente non sono daccordo con la tua affermazione, ma sta bene così non intendo convincere nessuno :)

# re: Il movimento NoSQL

@Fabrizio. Per motivi completamente slegati da questo post e commenti ho appena postato un test che ho fatto per un lavoro reale dove si sta valutando l'uso di MongoDB.
Almeno i test bisognerebbe farli prima di prendere una strada. Consapevolezza prima di tutto.

Per la community ti faccio i miei complimenti. Se hai voglia di contattarmi in privato, sto portando avanti un iniziativa di cui vorrei parlarti che riguarda le community italiane e che gli altri hanno già avuto modo di conoscere. Magari vi/ti può interessare.