[Python] python SQL?

[enrico franchi]

2014-02-16 7:51 GMT+00:00 Carlos Catucci <carlos.catucci a gmail.com>:

>
> De gustibus non disputandum est.
>

Sulle cose tecniche di solito non e' questione di *gusti*.

Ci sono due questioni principali. Una completamente filosofica:

1. Ci sono un botto di pattern architetturali per fare ORM. I piu' popolari
fuori da casa ms sono active record e data mapper. Guarda caso, nessuno dei
due e' perfetto. Il motivo e' che il problema di mappare il modello
relazionale sul modello ad oggetti e' vagamente ill-defined per vari motivi
(fra cui il fatto che il modello ad oggetti e' un pochetto ill-defined di
suo e soprattutto tende ad ammettere piu' soluzioni ad uno stesso problema
con differenti trade-offs). Per cui anche a livello teorico si hanno vari
compromessi... e.g., il design di active record e' molto leaky, data mapper
e' relativamente complesso concettualmente.

Ma poi proprio semplicemente ci sono cose molto naturali nel mondo ad
oggetti che si mappano malissimo nel mondo relazionale e viceversa. E per
queste situazioni l'orm non e' che puo' fare davvero molto...

La seconda molto pratica: quello che e' un ORM e' un oggetto appiccicato
sopra uno dei colli di bottiglia tipici delle applicazioni. Il che vuole
dire che e' veramente molto sensibile alle performance. E semplifica molto
la scrittura di query inefficienti. Ora, come si puo' notare dalla
permanenza in una qualunque lista come questa, se le persone hanno una
feature vagamente comoda da usare, ne abuseranno inconsapevolmente,
insegneranno ad altri il loro trucco e poi si lamenteranno che tutto va
piano (appena i dati crescono). Siccome sono clueless, ovviamente non
avranno idea di quello che e' successo e risolveranno in vari modi
(prendendo un consulente, generalmente per un altro linguaggio, cambieranno
database, riscriveranno tutto, andranno avanti a lamentarsi senza fare
nulla, dando la colpa a componenti casuali dell'architettura). Ora in tutto
questo non e' che ci sia nulla di male, semplicemente il fatto e' che cose
facili da fare e drammaticamente inefficienti saranno fatte
*inconsapevolmente*.

Il punto chiave e' che la gente pensa architetture varie ad oggetti e
sfruttera' la flessibilita' dell'orm per martellarci dentro il pattern di
accesso ai dati che piu' gli pare, non necessariamente uno buono.

Su tutto questo, si infila il problemino tipico dei linguaggi ad oggetti: i
dati occupano quintali di memoria non necessaria perche' sono pesantemente
nested. E avere un sistema comodo per generare una comoda interfaccia ad
oggetti vuole dire che le cose saranno fatte cosi'.

E voglio dire... ricordati che i dati nel db sono, auspicabilmente univoci.
tipicamente hai un db per applicazione, dentro cui hai i dati. un db
logico: potrebbe essere shardato, auspicabilmente e' replicato, etc etc
etc. I dati sono li e non danno fastidio.

Poi scopri che hai una piccola flotta di server. Ciascuno di questi tira su
un po' di worker. Ed ecco che le query che ti tirano su x MB di oggetti, in
realta' finisce che ti tirano su x00 MB *globalmente*. E cominci ad avere
problemi. E si, memcache, orpelli, cazzi e mazzi.

Oh, poi voglio dire, se hai un magazzino con duemila oggetti, chissene. Se
devi fare il payroll per duecento dipendenti, chissene. Se devi fare il
blog, il forum e chissene... il problema e' che non scala. Non scala. Non
ci sono cazzi.



> Io personalmente li trovo comodi. Il non dover impazzire tra dialetti, il
> poter svilupppare in locale, per dire, su Sqlite e poi andare in produzione
> con Postgres, cosa che mi facilita di molto le cose (per dirne una se
> aggiungo dati di test alla base dati un push sul repo condiviso (*) rende
> disponibile la cosa a tutti i coinvolti nel progetto senza dover eseguire
> un dump da allegare e un db_restore dopo un pull) senza impazzire sui
> dialetti e sulle varie differenze (sacrosante, ciascun Db ha il suo motivo
> di esistere, di essere specializzato in qualcosa, tranne forse un paio).
>

Comodo, forse. Stiamo pero' contando *molto* che l'astrazione sia perfetta
e non si stia nascondendo un baco che ti comparira' sulle macchine di test
o addirittura in produzione. Vuole anche dire che non puoi usare nulla di
specifico di PostgreSQL, che, sebbene accettabile, e' comunque una forte
limitazione.

Poi ovvio che se devo fare una query particolarmente incasinata (e accade
> SOLO se lavoro su basi dati esistenti, in caso contrario se e' roba mia
> parto dal presupposto di avere sbagliato l'architettura e riprogetto di
> conseguenza) posso usrae una raw, ma deve essere davvero un caso limite
> dove l'ORM non ce la fa.
>

L'architettura del db deve essere *sempre* il piu' efficiente possibile. Se
no, non ja fa. E si, sharda, cazzi e mazzi, per carita'.

Il problema e' che anche su query relativamente semplici succedono cose.


>
> Lo so, mi direte che l'ORM non ottimizza come puo' fare una query scritta
> ad hoc, ma a volte la flessibilita' conta piu' delle prestazioni.
>

Non nel mio caso. Aggiungere host non necessari cessa di scalare abbastanza
presto.



-- 
.
..: -enrico-
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.python.it/pipermail/python/attachments/20140216/46c38f0b/attachment.html>