[Python] O non capisco sqlite, o non capisco sqlalchemy, o entrambi

[Pietro Battiston]

Il giorno lun, 18/11/2013 alle 17.22 +0100, Matteo Vitturi ha scritto:
> [...]
> > 
> > Per capire, mi sono andato a vedere la query che sqlalchemy genera,
> ed è
> > come segue:
> > 
> > "SELECT a.id AS a_id, a.col AS a_col FROM a, arel WHERE ? = arel.id1
> AND
> > a.id = arel.id2", la_mia_id
> > 
> > Provando a chiamare direttamente questa query direttamente con
> sqlite,
> > in effetti ottengo lo stesso effetto che usando l'ORM di slqalchemy.
> > 
> > Ora, le mie conoscenze/ricerche di SQL sono sufficienti per farmi
> capire
> > che questa è una JOIN implicita, e qual'è la sua logica. Però non
> > capisco:
> > 1) dal punto di vista implementativo: com'è possibile che una JOIN
> sia
> > così più lenta di svariate SELECT che fanno (concettualmente, per
> quel
> > che ne posso capire) esattamente lo stesso lavoro?!
> > 2) ammesso che debba essere così, cosa impedisce a sqlalchemy di
> usare
> > le stesse SELECT che uso io, per recuperare esattamente la stessa
> roba?!
> [...]
> > Pietro
> 
> Sqlite accede a AREL cercando id1=la_mia_id: in assenza di indice su
> AREL.id1 effettua una ricerca lineare. Supponiamo pure che questo per
> scorrere tutta la tabella serva un decimo di secondo.
> Per ogni riga ottenuta accede alla tabella A cercando quale "id"
> batta: in assenza di indice su A.id effettua una ricerca lineare, ogni
> volta impiegando un decimo di secondo per scorrere tutta la tabella.
> Ora, con milioni di decimi di secondo si si arriva facilmente a
> qualche giorno di esecuzione...
> 
> Aggiungi due indici.

Grazie! (anche a Simone e Manlio) Sarà ormai charo a tutti che,
parafrasando il Subject, non avevo capito più o meno nulla.

(quello che mi fregava è che gli indici sulle colonne id delle tabelle
principali erano stati creati automagicamente, per cui lì tutto era
"naturalmente efficiente" - ben sotto il costo di una ricerca lineare -
e non capivo perché non lo fosse sulle secondarie)

Pietro