[Python] Applicazione WEB con Python e Postgresql

Daniele Varrazzo piro a develer.com
Mar 23 Set 2014 19:27:01 CEST


On 2014-09-23 17:42, Simone Federici wrote:
> Daniele Varrazzo:
>>
>> Non lo so
>
>
> si che lo sai :-)

Giuro che non conosco oracle, db2, sql server, firebird. Informix un 
pochino si' ma sto cercando di smettere. Quindi come si implementi la 
feature X sul database Y il mio programma di immissione di ore dei 
dipendenti per l'amico di mio padre che ha una ditta con 6 impiegati non 
lo sapra' fare. Probabilmente funzionera' bene solo su sqlite (postgres 
se i dipendenti diventano 8) e non mi metto a scaricare una copia pirata 
di sql server per testarlo li'.


>> Se uno ha come obiettivo quello di scrivere un sito web puo' 
>> scegliere il
>> suo maledetto database e tenerselo stretto
>
>
> e una applicazione? un prodotto da vendere?

La mia applicazione come prerequisito ha (esempio) postgres. Se non hai 
i soldi per comprare una copia di postgres non la usi. *difficilmente* 
la tua applicazione sara' piu' economica di postgres, che e' gratuito, 
no?  Il mio prodotto da vendere ha come prerequisito (esempio) oracle: 
ce l'ha perche' da ogni licenza che oracle vende dal mio programma io ci 
becco un grasso 0.01% (che magari mi basta per comprare una Panda). 
Perche' mi dovrebbe interessare di supportare anche postgres? Me la 
compri tu la Panda?


>> L'indipendenza dal database e' un mito.
>
>
> direi che è complessa, ma non c'è nulla di mitologico.
> se è un requisito la devi implementare.

Si ma distingui quando e' un requisito da quando e' uno sfizio tuo. 
Come quell'altro dell'altro giorno che voleva Python 3.4 a girare su 
piattaforme degli anni 90: sfizio tuo? cazzi tuoi. Il cliente lo 
richiede? Paga e allora mi studio come si fa la paginazione in oracle e 
ti pagino anche mia zia. E se viene piu' facile farlo con un orm lo uso, 
ma l'utente paga anche quello, perche' fare le cose difficili con un orm 
e' piu' difficile che farle in altri modi. E magari nella Panda ci metto 
pure l'autoradio.


> poi c'è il polorfismo, con SQL vai di flatlogic, oppure ti riscrivi 
> in casa
> un orm.
>
> una query non è sempre lineare. ad esempio:
> - filtri e ricerche web. componi la tua query a suon di if? alcuni 
> devoni
> mettere in join altri no

Si', lo faccio (e l'ho fatto davvero), perche' la sintassi di un join 
di un singolo database e' facile. Il problema di risolverlo con tutti i 
database e' molto piu' difficile ma, hey, non e' un problema mio: lo 
dovevo risolvere solo in postgres.


> - profilazioni in base all'utente. scrivi tutte le sql query 2 volte? 
> se
> poi devi guardare anche i gruppi le scrivi 4 volte?

Non ho capito questo problema, ma direi che se non ci siamo capiti 
cosi' allora non ci vogliamo capire.


> insomma, spesso SQL è meglio di ORM. ma spesso non vuol dire sempre.

Si', se devi risolvere certi problemi sono d'accordo. Poi sta a te la 
saggezza di valutare se quel problema ce l'hai davvero, nel qual caso 
devi limitarti al minimo comune denominatore di tutti i db sopportati, 
mentre gli altri usano writable common table expression e indici gist su 
json come se non ci fosse un domani, e sono a casa per cena. Credi che 
quelli che hanno scritto Instagram si siano preoccupati di farlo 
compatibile con MySql?


-- Daniele


Maggiori informazioni sulla lista Python