E' sqlite ad esser buggato o sono io...?

[af101]

...o meglio, tu non hai trovato una funzione risolutiva, ma non è ben chiaro se esista o meno qualcosa, vista la macabra rappresentazione grafica presente )

... ed infatti spero che al più presto qualcuno ponga fine alla cosa e scriva una vera documentazione. Cioè, alcune cose son davvero buttate lì così, tanto per, senza spiegare nulla -.-"

Io, con quel poco che ricordo di SQL, ho trovato la documentazione abbastanza ben fatta; i diagrammi sintattici, in particolare, mi sono sembrati molto leggibili. Il punto è che si tratta di una documentazione da usare "per differenza" rispetto ad altra documentazione su SQL e su altri RDBMS. Non è un buon punto di partenza per chi debba imparare SQL, ma non mi pare il tuo caso, dati i tuoi destreggiamenti sintattici.

Quel che non ho capito però dalla tua risposta è se è normale ottenere un risultato simile dalla query "SELECT id_casa FROM case GROUP BY id_schiera ORDER BY id_casa ASC", o si tratta di boh qualcos'altro.

Ho parecchia ruggine da rimuovere, e un discreto aggiornamento da eseguire (l'ultima volta che ho scritto in SQL Oracle era appena uscita la versione 7 di Oracle, e il nostro ambiente usava la 5), ma direi che è normale, in assenza di funzioni di raggruppamento (p.es. la min(.) che ho inserito nella mia versione della tua query).

Cioè, forse non mi son spiegato, ma il mio dubbio è se mysql mi ha viziato e sqlite3 è pignolo, o se è lecito aspettarsi che l'ordinamento avvenga a monte del "group by".

Il punto sta nella scelta del candidato per rappresentare l'insieme selezionato; group by andrebbe usato sempre in congiunzione con una funzione di raggruppamento, risolvendo per costruzione il problema dell'identificazione del candidato. Dovrei vedere meglio i tuoi casi del passato, senza i quali posso formulare solo congetture - dato che non conosco i dettagli implementativi di MySQL, ma tenderei a ritenere che MySQL ti restituisse risultati più vicini alle tue aspettative per via di qualche ottimizzazione 'intelligente' presente nel suo motore, oppure -ma qui il grado di plausibilità è fortemente legato al numero di prove da te effettuato e alla loro diversità- potresti esserti trovato nella felice condizione di aver scritto query naturalmente indirizzate ad utilizzare il candidato selezionato dall'engine di MySQL, senza l'intervento di un'euristica sofisticata.

Passo all'altra tua domanda più corposa;

ciao,

Andrea.

[af101]

Il problema penso sia legato al fatto che la query che mi serve fare, è in realtà il risultato di un'altra query (annidata chiaramente all'interno), con delle colonne create appositamente, cioè anch'esse risultato di un'altra query.

Avrei bisogno di vedere il codice per fornire una risposta più precisa, ma il punto, in essenza, resta sempre come trattare il fatto che devi ordinare prima di raggruppare, mentre la semantica SQL ordina dopo aver eseguito il group by, e dopo aver scelto un candidato, quando non sia univoco. Se non risulta possibile scrivere una funzione di raggruppamento da utilizzare direttamente nella parte di result-column della select, il ricorso a query nidificate è inevitabile, a meno di spezzare la query in più porzioni, per mezzo di tabelle di appoggio esplicite, il che non cambia la sostanza della questione.

Saluti,

Andrea.

[bigalex]

Quindi tutto il nocciolo del problema riguarda il fatto che sqlite - almeno per quanto io sappia - non riesce ad ordinare prima del raggruppamento, o meglio, non è possibile raggruppare tenendo i primi valori trovati e non gli ultimi.
Se questo fosse vero (e sinceramente non saprei dirti se lo è, non avendo mai lavorato prima d'ora con sqlite nè con sqlite3, ed essendo viziato dalla documentazione particolarmente chiara e piena d'esempi di mysql ), si renderebbe quindi necessaria una struttura simile a quella da me fatta.
La cosa che mi sconvolge però è dovergli invertire l'ordine prima, fare il "group by", e reinvertire ancora l'ordine dopo... cioè, io vedo che due passaggi su tre sono futili... -.-"
Spezzare la query, nel mio caso, non è sensato perchè andrebbe a complicare una situazione già complicata di per sè (e quel che mi fa rabbia è che invece sarebbe semplice -.-")
Non vi incollo i dettagli della query perchè dovreste studiarvi la mia implementazione, la struttura delle tabelle... e poi beh perchè essendo il cuore della mia applicazione (che conto di vendere ) diventerebbe un pò ahem... open source

Tornando sulla documentazione, eh sì, è completa, o meglio, i diagrammi sintattici ci son tutti ed è tutto documentato, ma per chi come me che è abituato a vedere esempi su esempi (parlo della documentazione di mysql), descrizione accurata (e basilare) di ogni funzione... beh, ci si trova sconcertati di fronte ad un tale riassunto insomma
Lasciando perdere che poi è da integrare con altro, ma un esempio ogni tanto non farebbe male insomma :P

Quindi riguardo invece le mie esperienze passate, non saprei dirti, o meglio, solitamente credo (ma la tua analisi ha certamente mostrato più esperienza di quanta io possa averne accumulata in questi anni!) di aver correttamente selezionato il candidato giusto, ma non escludo che qualche ottimizzazione eucaristica possa aver giocato dalla mia parte.

Quel che ho notato invece in sqlite è che spesso gli errori non son segnalati.
Ad esempio, in mysql quando faccio una query annidata, mi viene richiesto (e spesso, preso dal resto della query me ne dimentico) di assegnargli un alias. Altrimenti non va affatto.
Con sqlite invece il controllo è più ahem... "lite"
Ho infatti provato senza l'assegnazione dell'alias, e si occupa da solo della gestione della query; ovviamente in caso di ambiguità sceglierà il risultato sbagliato (e pur che scegliesse il risultato corretto sarebbe comunque rischioso lasciar la query così com'è), e quindi è comunque necessaria una definizione... solo che nessuno me lo ricorda ed errare è umano
Sì, senza dubbio son stato viziato da mysql

Mi fa piacere aver "risolto" (a meno che non arrivi qualcuno che s'intenda di sqlite e riporti la sacra annunciazione della soluzione ) il problema, e ringrazio tutti della collaborazione, sarete nei credits del programma

Noto però con mio dispiacere che i post sul forum son più che altro legati a problemi di coloro che si stanno avvicinando da poco alla programmazione di android e me ne dispiaccio molto, sarebbe bello avere un luogo dove condividere esperienze (ma soprattutto problemi con annesse soluzioni!) di programmi anche un pò più complessi, facendo crescere una community italiana di sviluppo.
Beh, io certamente se dovessi avere qualche altro problema vi terrò informati, e sto tenendo d'occhio i thread più nuovi, quindi spero di poter aiutare anche io voi com'è stato fatto con me

Buona serata a tutti e grazie ancora!

[af101]

Quindi tutto il nocciolo del problema riguarda il fatto che sqlite - almeno per quanto io sappia - non riesce ad ordinare prima del raggruppamento, o meglio, non è possibile raggruppare tenendo i primi valori trovati e non gli ultimi.

Direi che il nocciolo è che SQLite esegue delle ottimizzazioni che sono solo parzialmente contollabili, e che occorre capirle più a fondo per dirigerle come ci occorre.

Tornando sulla documentazione, eh sì, è completa, o meglio, i diagrammi sintattici ci son tutti ed è tutto documentato, ma per chi come me che è abituato a vedere esempi su esempi (parlo della documentazione di mysql), descrizione accurata (e basilare) di ogni funzione... beh, ci si trova sconcertati di fronte ad un tale riassunto insomma
Lasciando perdere che poi è da integrare con altro, ma un esempio ogni tanto non farebbe male insomma :P

Il confronto tra le due documentazioni è davvero fuori discussione


Per chiudere la questione sull'ottimizzazione, propendo fortemente per una differenza significativa nell'euristica di esecuzione della query da parte dei due motori, in particolare in presenza di un'indicizzazione sulle colonne coinvolte nella select; confrontando

MySQL :: MySQL 5.0 Reference Manual :: 7.2.14 GROUP BY Optimization

e il punto 6 di

The SQLite Query Optimizer Overview

la differenza risulta vidente.

Ora, dato che noi, a meno di trovare un'altra implementazione di un motore SQL sufficientemente leggero da poter girare sui nostri smartphone, è in termini SQLite-iani che dobbiamo ragionare, dobbiamo allenarci per produrre la query ottimale secondo SQLite...

Ciao,

Andrea.