[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