<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">2014-02-16 7:51 GMT+00:00 Carlos Catucci <span dir="ltr"><<a href="mailto:carlos.catucci@gmail.com" target="_blank">carlos.catucci@gmail.com</a>></span>:<br>

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><br>De gustibus non disputandum est. </div>

</div></blockquote><div><br></div><div>Sulle cose tecniche di solito non e' questione di *gusti*.</div><div><br></div><div>Ci sono due questioni principali. Una completamente filosofica:</div><div><br></div><div>1. Ci sono un botto di pattern architetturali per fare ORM. I piu' popolari fuori da casa ms sono active record e data mapper. Guarda caso, nessuno dei due e' perfetto. Il motivo e' che il problema di mappare il modello relazionale sul modello ad oggetti e' vagamente ill-defined per vari motivi (fra cui il fatto che il modello ad oggetti e' un pochetto ill-defined di suo e soprattutto tende ad ammettere piu' soluzioni ad uno stesso problema con differenti trade-offs). Per cui anche a livello teorico si hanno vari compromessi... e.g., il design di active record e' molto leaky, data mapper e' relativamente complesso concettualmente.</div>

<div><br></div><div>Ma poi proprio semplicemente ci sono cose molto naturali nel mondo ad oggetti che si mappano malissimo nel mondo relazionale e viceversa. E per queste situazioni l'orm non e' che puo' fare davvero molto...</div>

<div><br></div><div>La seconda molto pratica: quello che e' un ORM e' un oggetto appiccicato sopra uno dei colli di bottiglia tipici delle applicazioni. Il che vuole dire che e' veramente molto sensibile alle performance. E semplifica molto la scrittura di query inefficienti. Ora, come si puo' notare dalla permanenza in una qualunque lista come questa, se le persone hanno una feature vagamente comoda da usare, ne abuseranno inconsapevolmente, insegneranno ad altri il loro trucco e poi si lamenteranno che tutto va piano (appena i dati crescono). Siccome sono clueless, ovviamente non avranno idea di quello che e' successo e risolveranno in vari modi (prendendo un consulente, generalmente per un altro linguaggio, cambieranno database, riscriveranno tutto, andranno avanti a lamentarsi senza fare nulla, dando la colpa a componenti casuali dell'architettura). Ora in tutto questo non e' che ci sia nulla di male, semplicemente il fatto e' che cose facili da fare e drammaticamente inefficienti saranno fatte *inconsapevolmente*.</div>

<div><br></div><div>Il punto chiave e' che la gente pensa architetture varie ad oggetti e sfruttera' la flessibilita' dell'orm per martellarci dentro il pattern di accesso ai dati che piu' gli pare, non necessariamente uno buono. </div>

<div><br></div><div>Su tutto questo, si infila il problemino tipico dei linguaggi ad oggetti: i dati occupano quintali di memoria non necessaria perche' sono pesantemente nested. E avere un sistema comodo per generare una comoda interfaccia ad oggetti vuole dire che le cose saranno fatte cosi'.</div>

<div><br></div><div><div>E voglio dire... ricordati che i dati nel db sono, auspicabilmente univoci. tipicamente hai un db per applicazione, dentro cui hai i dati. un db logico: potrebbe essere shardato, auspicabilmente e' replicato, etc etc etc. I dati sono li e non danno fastidio.</div>

</div><div><br></div><div>Poi scopri che hai una piccola flotta di server. Ciascuno di questi tira su un po' di worker. Ed ecco che le query che ti tirano su x MB di oggetti, in realta' finisce che ti tirano su x00 MB *globalmente*. E cominci ad avere problemi. E si, memcache, orpelli, cazzi e mazzi.</div>

<div><br></div><div>Oh, poi voglio dire, se hai un magazzino con duemila oggetti, chissene. Se devi fare il payroll per duecento dipendenti, chissene. Se devi fare il blog, il forum e chissene... il problema e' che non scala. Non scala. Non ci sono cazzi.</div>

<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra">

Io personalmente li trovo comodi. Il non dover impazzire tra dialetti, il poter svilupppare in locale, per dire, su Sqlite e poi andare in produzione con Postgres, cosa che mi facilita di molto le cose (per dirne una se aggiungo dati di test alla base dati un push sul repo condiviso (*) rende disponibile la cosa a tutti i coinvolti nel progetto senza dover eseguire un dump da allegare e un db_restore dopo un pull) senza impazzire sui dialetti e sulle varie differenze (sacrosante, ciascun Db ha il suo motivo di esistere, di essere specializzato in qualcosa, tranne forse un paio).</div>

</div></blockquote><div><br></div><div>Comodo, forse. Stiamo pero' contando *molto* che l'astrazione sia perfetta e non si stia nascondendo un baco che ti comparira' sulle macchine di test o addirittura in produzione. Vuole anche dire che non puoi usare nulla di specifico di PostgreSQL, che, sebbene accettabile, e' comunque una forte limitazione.</div>

<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra">Poi ovvio che se devo fare una query particolarmente incasinata (e accade SOLO se lavoro su basi dati esistenti, in caso contrario se e' roba mia parto dal presupposto di avere sbagliato l'architettura e riprogetto di conseguenza) posso usrae una raw, ma deve essere davvero un caso limite dove l'ORM non ce la fa.</div>

</div></blockquote><div><br></div><div>L'architettura del db deve essere *sempre* il piu' efficiente possibile. Se no, non ja fa. E si, sharda, cazzi e mazzi, per carita'.</div><div><br></div><div>Il problema e' che anche su query relativamente semplici succedono cose.</div>

<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">

<div class="gmail_extra"><br></div><div class="gmail_extra">Lo so, mi direte che l'ORM non ottimizza come puo' fare una query scritta ad hoc, ma a volte la flessibilita' conta piu' delle prestazioni.</div>

</div></blockquote><div><br></div><div>Non nel mio caso. Aggiungere host non necessari cessa di scalare abbastanza presto. </div></div><br><br clear="all"><div><br></div>-- <br> .<br>..: -enrico-
</div></div>