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
_______________________________________________
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python
