[Python] Django + Postgres

[Alberto Granzotto]

2013/12/15 Marco Beri <marcoberi a gmail.com>

>  > per un progetto sono tornato al caro vecchio SQL, dopo un bel po' di
> tempo su MongoDB.
>
> Posso chiederti come mai?
>

Per diversi motivi:

- 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.

 - la potenza espressiva di SQL e' difficile da raggiungere

 - 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

 - non ho mai usato Postgres in produzione (eh, ok, chi e' senza peccato
scagli `SELECT * FROM stones LIMIT 1`)

 - mi sembra un approccio piu' agile*


* Vi condivido un pensiero personale che non ho ancora studiato a fondo, ma
ve lo butto la' perche' mi piacerebbe ragionarci.
Si dice che MongoDB sia
agile<http://www.mongodb.com/blog/post/why-mongodb-popular>,
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, che si puo'
stampare<http://django-extensions.readthedocs.org/en/latest/graph_models.html>,
e che migliora la collaborazione e la comunicazione all'interno del team.
In MongoDB e' tutto dentro il DB.

> 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)?
>
> Quando serve io. E quando serve non puoi farne a meno.
>
> > O preferite tenere tutto a livello applicativo per portabilita'?
> >
> > Domanda molto aperta, me ne rendo conto, ma sono curioso di raccogliere
> qualche caso d'uso per sapere come vi comportate voi.
>
> 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.
> Pochi piedi in giro, scommetto :-)
>

D'accordo.


> Guarda questo video: http://www.youtube.com/watch?v=C3bZbA4jaAg
>

Poi me lo guardo :)


> Purtroppo non trovo le slide col cellulare.
>

ma hai scritto tutto da cellulare? hardcore.


>  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.
>

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.


> Ecco, magari le mie stored procedure le metterei qui:
> https://docs.djangoproject.com/en/1.6/howto/initial-data/#providing-initial-sql-data
>
Grazie!


> Almeno sono pure versionate.
>
ciao,
Alberto
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.python.it/pipermail/python/attachments/20131215/0999a228/attachment.html>