Critica a Una Base di Dati Su FileSystem

Ho letto un articolo che ... devo dire che ha suscitato la mia ilarità. Di seguiti i miei commenti...

NOTA: Su richiesta dell'autore non cito il link e non cito il suo nome. Dovete essere proprio dei falchi per associare l'articolo e la persona. L'autore ha risposto e non si è divertito, ma tanto sappia che questa pagina non è linkata sul menu del sito e quindi si può trovare solo sulla sitemap e riceve pochissime visite (praticamente casuali). Però l'articolo mi pare divertente e quindi non ho voglia di cancellarlo dalla rete.

"Sono recentemente stato ad un seminario in SUN dove si discuteva ... di programmazione ad oggetti"

Mi sembrerebbe strano infatti, che si parlasse infatti in un seminario su Java di come si cucina il pollo alla livornese.

"non si può considerare propriamente 'ad oggetti' una applicazione che faccia uso di un DBMS per la persistenza di dati"

Quindi se qualcuno di voi utilizza un database è finito, che sia in Java, C++, etc. Il suo programma NON può essere considerato a oggetti, comunque venga scritto. Tornate quindi al COBOL, che ci fate maggior figura.

"l'integrazione di pezzi di linguaggio SQL all'interno del codice, come li metti li metti, fa a botte con l'intento originario."

Ma veramente in questo momento a me verrebbe di fare a botte riguardo il database che annulla la OOP...

"Come quando hai fretta di uscire di casa, non trovi le chiavi, le cerchi dappertutto e alla fine qualcuno ti fa gentilmente notare che le hai sempre avute in mano! "

Appropriato e calzante. Non trovi la persistenza dei dati, anche se il database ce l'hai sempre avuto in mano...

"Beh la risposta ovviamente è stata: se devi rendere persistente qualcosa, ti inventi quello che ti pare, che so, un file di properties su FileSystem..."

Un database, no? A proposito di chiavi che hai in mano e non trovi...

"Tornando a casetta ho deciso: il DBMS me lo faccio da solo!"

E già che ci sei, ti riscrivi anche il kernel e la gui, e anche il word processor...

"ma un file di properties come lo gestisco? È naturale! Con java.util.Properties!"

Mannò io credevo che si dovesse usare il form editor del Visual Basic...

"la classe java.util.Properties ha poi due metodi in particolare cjhe lo fanno addirittura assomigliare ad un entity EJB!"

Si, certo. Come una giraffa assomiglia a un dromedario. Hanno tutti e due la testa!

"forse la mia applicazione non sarà poi così performante in termini di velocità"

Come, non è performante? E perchè mai? Vuoi dire che quelli che fanno i db lo fanno meglio di te? Non ci credo!

"sicuramente non ho affrontato questioni delicate come la gestione di transazioni e accesso concorrente con lock sui file, il discorso si complicherebbe"

Maddai, se il database te lo fai da solo, due righe di codice in più e metti le transazioni e l'accesso concorrente. Non ti sottovalutare.

"Adottare questo tipo di persistenza mi risparmia l'installazione di un DBMS"

Ummi vuoi dire che SE NON USI un database, allora NON LO DEVI INSTALLARE? Oddio non ci avevo pensato, è vero!

"si fa sempre in tempo a cambiare se si è avuta cura di strutturare l'applicazione in modo appropriato"

Quindi se si è fatto una cazzata, ma ci si è accorti che si sta facendo una cazzata, SE mentre la si fa ci si premunisce, alla fine si può tornare sui propri passi e non fare la cazzata che si è fatto. O meglio fare finta di non aver fatto la cazzata...

A proposito, l'intero articolo è praticamente la gestione di un file di configurazione. Lo faccio come esercizio nei corsi per metterci i dati per LA CONNESIONE AL DATABASE. Non è che hai scambiato la gestione del file di configurazione per l'accesso al database... per il database?

Certo, se questo è un argomento interessante ... il prossimo che tratterà? Usi e costumi della stringa e come fare a concatenare efficientemente con uno string buffer?