Dottori, il 30 Settembre a Mllano si svolgerà il bzaarcamp, un BarCamp italiano che radunerà le migliori menti della nostra nazione che non hanno nient’altro di meglio da fare. 
L’evento è speciale e chiunque può partecipare, e, se lo vuole, può portare un argomento di cui parlare.
Io, miei cari, non so di cosa parlare, ma mi sembra che partecipare senza fare nulla e solo ascoltando sia un po’ come sfruttare le conoscenze altrui.
Quindi, ho postato nella lista degli argomenti possibili, una presentazione di uno dei libri di fantascienza che preferisco: Un cantico per Leibowitz di Walter M. Miller Jr.
La cosa non c’entra niente con il resto degli interventi, ma proprio per questo mi stuzzica.
Se avete qualche idea alternativa, proponetela, parlare a ruota libera di argomenti che non conosco è il secondo dei miei hobby.
Categoria: informatica
Database ad oggetti?
Chiunque abbia fatto un po’ di programmazione ad oggetti sa benissimo che le difficoltà più grandi si affrontano quando si deve gestire la persitenza delle informazioni.
Questo perché il nostro modello ad oggetti deve essere salvato su un database che nella totalità dei casi è un database relazionale. Cioè fatto di tabelle piatte su cui salvare i dati. Questo porta ad una dicotomia (impedance mismatch): da una parte il modello usato dai programmi applicativi dovrebbe essere quanto più ad oggetti, dall’altra il modello deii dati sul database deve essere puramente relazionale.
Il problema viene risolto in vari modi: si può sacrificare il modello ad oggetti alla logica del database, individuando come oggetti le tabelle dove andranno a salvarsi i dati oppure si può utilizzare uno strato di software che si occupa di fare la conversione tra i due modelli.
Entrambi i metodi hanno, chiaramente, degli svantaggi, sia dal punto di vista delle performance, sia dal punto di vista della manutenibilità del codice e della sua chiarezza.
Una soluzione, che già era stata percorsa una decina di anni fa con scarsi risultati, è quella di avere dei database ad oggetti, che salvano gli oggetti mantenendone le caratteristiche.
Uno di questi è db4o (db for objects), che è rilasciato mediante GPL per scopi non commerciali (una licenza uguale a quella di MySQL). Scritto in versione java e .NET, fornisce al programmatore delle semplici API che consentono di salvare oggetti complessi direttamente con una istruzione.
Certo si perde tutto l’SQL, la teoria sulle normalizzazioni e gli RDBMS, ma ci si può fare un pensierino per modelli ad oggetti di una certa complessità.
Qui e qui approfondimenti sul tema.
Dottori, non preoccupatevi, sto bene (si fa per dire, naturalmente), è che volevo un po’ fare il Beggi, oppure il Fullo.
Questo perché il nostro modello ad oggetti deve essere salvato su un database che nella totalità dei casi è un database relazionale. Cioè fatto di tabelle piatte su cui salvare i dati. Questo porta ad una dicotomia (impedance mismatch): da una parte il modello usato dai programmi applicativi dovrebbe essere quanto più ad oggetti, dall’altra il modello deii dati sul database deve essere puramente relazionale.
Il problema viene risolto in vari modi: si può sacrificare il modello ad oggetti alla logica del database, individuando come oggetti le tabelle dove andranno a salvarsi i dati oppure si può utilizzare uno strato di software che si occupa di fare la conversione tra i due modelli.
Entrambi i metodi hanno, chiaramente, degli svantaggi, sia dal punto di vista delle performance, sia dal punto di vista della manutenibilità del codice e della sua chiarezza.
Una soluzione, che già era stata percorsa una decina di anni fa con scarsi risultati, è quella di avere dei database ad oggetti, che salvano gli oggetti mantenendone le caratteristiche.
Uno di questi è db4o (db for objects), che è rilasciato mediante GPL per scopi non commerciali (una licenza uguale a quella di MySQL). Scritto in versione java e .NET, fornisce al programmatore delle semplici API che consentono di salvare oggetti complessi direttamente con una istruzione.
Certo si perde tutto l’SQL, la teoria sulle normalizzazioni e gli RDBMS, ma ci si può fare un pensierino per modelli ad oggetti di una certa complessità.
Qui e qui approfondimenti sul tema.
Dottori, non preoccupatevi, sto bene (si fa per dire, naturalmente), è che volevo un po’ fare il Beggi, oppure il Fullo.