<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">2013/12/15 Marco Beri <span dir="ltr"><<a href="mailto:marcoberi@gmail.com" target="_blank">marcoberi@gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

<div class="im">
<p dir="ltr">> per un progetto sono tornato al caro vecchio SQL, dopo un bel po' di tempo su MongoDB.</p>
</div><p dir="ltr">Posso chiederti come mai? </p></blockquote><div><br></div><div>Per diversi motivi:<br></div><div> <br></div><div>- Mongo e' figo e comodo, spesso c'e' un rapporto 1:1 tra i documenti nel DB e le View. Quello che cerco di fare con mongo mediamente e' storare documenti che posso prendere e renderizzare con pochissima manipolazione, magari con qualche read in piu'. Ma mi sono anche accorto che questa comodita' la paghi nel momento in cui devi fare query per generare nuovi dati e informazioni. Non che non si possa fare, ma ad esempio aggregare i dati con l'aggregation framework di MongoDB e' un ginepraio. Pensa che una volta, preso dalla disperazione, ho migrato i dati da MongoDB a MariaDB con uno script e c'ho dato di un delizioso SQL con varie GROUP BY etc.<br>

</div><div><div><br></div> - la potenza espressiva di SQL e' difficile da raggiungere<br><br></div><div> - prototipare qualcosa velocemente con un framework che conoscevamo (nel nostro caso Django) e avere anche un pannello di amministrazione "gratis", aka `django.contrib.admin`. Rimanendo quindi nell'ambito del framework abbiamo usato la naturale scelta di SQL<br>

</div><br><div> - non ho mai usato Postgres in produzione (eh, ok, chi e' senza peccato scagli `SELECT * FROM stones LIMIT 1`)<br><br></div><div> - mi sembra un approccio piu' agile*<br><br><br></div><div>* Vi condivido un pensiero personale che non ho ancora studiato a fondo, ma ve lo butto la' perche' mi piacerebbe ragionarci.<br>

</div><div><a href="http://www.mongodb.com/blog/post/why-mongodb-popular">Si dice che MongoDB sia agile</a>, che non sei piu' schiavo di schemi. No. A me sembra che la vera agilita' sia data dall'avere i dati nella terza forma normale. Hai tutti i tuoi "atomi" di dati sparsi in giro, e joinando gli dai valore e li trasformi in informazioni. Con SQL puoi generare le informazioni che vuoi all'interno del tuo universo di tuple. E sono tante, sono il prodotto cartesiano di tutte le tabelle (OK, considerando le JOIN ci sono dei vincoli da rispettare, quindi sono meno del prodotto cartesiano). Secondo me la vera cosa che rende schiavi e' l'avere dei dati semi-denormalizzati. Inoltre usare SQL significa avere uno schema, <a href="http://django-extensions.readthedocs.org/en/latest/graph_models.html">che si puo' stampare</a>, e che migliora la collaborazione e la comunicazione all'interno del team. In MongoDB e' tutto dentro il DB.<br>

</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="im">
<p dir="ltr">> Quanti di voi usano Django ma fanno lavorare anche a trigger e procedure di Postgres, ad esempio per aggiornare in modo trasparente alcuni campi aggregati (es. totali)?</p>
</div><p dir="ltr">Quando serve io. E quando serve non puoi farne a meno. </p><div class="im">
<p dir="ltr">> O preferite tenere tutto a livello applicativo per portabilita'?<br>
><br>
> Domanda molto aperta, me ne rendo conto, ma sono curioso di raccogliere qualche caso d'uso per sapere come vi comportate voi.</p>
</div><p dir="ltr">Come dice C8E la portabilitā č un falso mito. Chi ha mai migrato un progetto tra due db diversi alzi la mano? E chi di questi pochi l'ha fatto senza problemi grazie ad un orm alzi un piede.<br>
Pochi piedi in giro, scommetto :-) </p></blockquote><div><br></div><div>D'accordo.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">


<p dir="ltr">Guarda questo video: <a href="http://www.youtube.com/watch?v=C3bZbA4jaAg" target="_blank">http://www.youtube.com/watch?v=C3bZbA4jaAg</a></p></blockquote><div><br></div><div>Poi me lo guardo :)<br></div><div>

 </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<p dir="ltr">Purtroppo non trovo le slide col cellulare. <br></p></blockquote><div><br></div><div>ma hai scritto tutto da cellulare? hardcore.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

<p dir="ltr">
Comunque ha mostrato un esempio di una query generata dall'orm di django che impegnava due minuti e la stessa query fatta a mano e mi pare inglobata in una stored procedure ci metteva 20 millisecondi. </p></blockquote>

<div><br></div><div>Non sono mai stato un enorme fan degli ORM. Delle volte e' piu' facile fare una query a mano con SQL che trovare la corretta combinazione di metodi delle API dell'ORM. Mi vanno bene invece quando devo scrivere.<br>

</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<p dir="ltr">Ecco, magari le mie stored procedure le metterei qui: <a href="https://docs.djangoproject.com/en/1.6/howto/initial-data/#providing-initial-sql-data" target="_blank">https://docs.djangoproject.com/en/1.6/howto/initial-data/#providing-initial-sql-data</a></p>

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

<p dir="ltr">Almeno sono pure versionate. </p></blockquote></div>ciao,<br>Alberto<br></div></div>