[Risolto] DB.SqLite - volumi supportabili

[Gianluigi]

Ho creato due nuove app di test, che allego, una che usa le date Integer e l'altra String.
Inserisce e toglie indici anche se quello possibilmente utile è sulla colonna date.
Il filtro sull'intervallo data va usato su piccoli intervalli max due settimane, ed è già molto lento, se non vogliamo attese interminabili (con e senza filtro).
Sarei curioso se Tornu lo provasse e lo confrontasse con mySQL per vedere le differenze, naturalmente cambiando in mySQL le date nel giusto valore.

Acc. come è tardi vado a dormire... 

P.S. Ho rimosso gli allegati potete scaricare da qui (per ora solo quello con date stringa)

[Picavbg]

Effettivamente la data che avevo dato nella prova precedente non era contenuta nel DB. Ho riprovato ed effettivamente è velocissimo. Tuttavia ho notato che il tuo DB contiene una sola tabella, mentre il mio ne contiene 11. Può darsi che ciò faccia la differenza.
Prima di rassegnarmi, vorrei provare a leggere la mia tabella d+movimgg tramite il "DB Browser for SQLite", però come al solito, prima devo imparare ad usarlo.

[Picavbg]

Incredibile!  Ho eseguito due modi diversi di vista dei alcuni record contenuti nella tabella movimgg indicata nel post precedente, la prima volta agendo sulla data direttamente nella casella filter, in testa alla colonna  DtCoMovgg, la seconda volta creando una vista attraverso la digitazione del comando sql preso dal mio programma. In entrambi i casi la risposta è stata praticamente immediata.
Ho rivisto la porzione di codice interessato a creare la vista corrispondente. Devo analizzare meglio il suo contenuto ed il n° di cicli che esegue nellla compisizione della gridview di destinazione, perchè a questo punto è il programma che ha una qualche anomalia di scrittura.

[Gianluigi]

Incredibile!  Ho eseguito due modi diversi di vista dei alcuni record contenuti nella tabella movimgg indicata nel post precedente, la prima volta agendo sulla data direttamente nella casella filter, in testa alla colonna  DtCoMovgg, la seconda volta creando una vista attraverso la digitazione del comando sql preso dal mio programma. In entrambi i casi la risposta è stata praticamente immediata.
Ho rivisto la porzione di codice interessato a creare la vista corrispondente. Devo analizzare meglio il suo contenuto ed il n° di cicli che esegue nellla compisizione della gridview di destinazione, perchè a questo punto è il programma che ha una qualche anomalia di scrittura.

Infatti, anche io ho postato dei programmi che non andavano bene perché con troppi loop.
Guada un po questo allegato che filtra migliaia di date in pochi attimi.
Occorre eliminare i loop ripetitivi.

P.S. Ho allegato anche quello con date integer, non mi pare ci siano differenze di nota nei tempi di esecuzione.

[tornu]

Ho visto che dalle risposte praticamente Picavbg ha trovato l'inghippo che rallentava la risposta della query che
interrogava il suo DB.
Volevo solo far notare a Picavbg che il numero di tabelle presenti in un DB non incide sulla velocità di risposta dello
stesso ma il numero di record che la tabella contiene (ma devono essere veramente tanti), se indicizzata correttamente,
che non ci siano dati ridondanti (se non in casi particolari) e come sono costruite le query Sql. Ovviamente come nel tuo
caso impatta anche Gambas, specialmente nel popolare Gridview, Listview e oggetti similari.
Comunque per curiosità provo il test proposto da Gianluigi, vi posterò i risultati.

[Picavbg]

Ho visto che dalle risposte praticamente Picavbg ha trovato l'inghippo che rallentava la risposta della query che
interrogava il suo DB.

Ancora non ho accertato in pieno tale inghippo. La mia è una deduzione logica, che deve essere ancora dimostrata.

Ho visto che dalle risposte praticamente Picavbg ha trovato l'inghippo che rallentava la risposta della query che
interrogava il suo DB.
Volevo solo far notare a Picavbg che il numero di tabelle presenti in un DB non incide sulla velocità di risposta dello
stesso ma il numero di record che la tabella contiene (ma devono essere veramente tanti), se indicizzata correttamente,
che non ci siano dati ridondanti (se non in casi particolari) e come sono costruite le query Sql. Ovviamente come nel tuo
caso impatta anche Gambas, specialmente nel popolare Gridview, Listview e oggetti similari.

Il mio DB non presenta dati ridondanti, a meno che non vogliamo considerare tali quelli costituenti le chiavi di accesso che in SQL si distinguerebbero in chiavi primarie e secondarie.
Credo anch'io che una parte di responsabilità sia da attribuire a classi come Gridview e Pdfwriter, fortemente utilizzate per arrivare alla composizione della vista  e stampa della query di rilevazione dati dal DB..
Infatti, quando accedo al DB per riprendere i dati di una data contabile da modificare o da completare la formazione delle righe della relativa Gridview è rapidissima, nonostante che vi siano interessate più tabelle del DB (adesso non ricordo quante esattamente).
All'epoca ho dichiarato come colonna indice   autoincrementale la prima di ciascuna tabella che riporta un numero progressivo di record, colonna praticamente insignificante.
Questa si potrebbe effettivamente eliminare e, di conseguenza anche l'indice.

[Picavbg]

Guada un po questo allegato che filtra migliaia di date in pochi attimi.
Occorre eliminare i loop ripetitivi.

Si, effettivamente è praticanmente istantaneo.
Bravissimo!

[Gianluigi]

Ho aggiunto anche il test con le date integer

[Gianluigi]

Comunque per curiosità provo il test proposto da Gianluigi, vi posterò i risultati.

Grazie  , l'unica prova significativa rimane quella tra due date molto distanti.

[Gianluigi]

C'era un bug nelle app, all'apertura con database già creato non inserivano il filtro, le ho aggiornate.

Al posto di c'era ho messo la cera, qualcuno è scivolato? 

[tornu]

Ho fatto la prova con il test proposto da Gianluigi su DB MySql, ho modificato quelle
parti di codice non compatibili con questo DB, i risultati non mi sembrano esaltanti per
200000 record. Vi posto le schermate e mi accingo a modificare il DB con le mie conoscenze,
vi posterò i risultati.

[Gianluigi]

In effetti se ci si limita ad interrogare DB Browser i risultati sono immediati 

179947 rows returned in 102ms from: SELECT *
FROM tuser
WHERE usdat >= '2009-11-09'
AND usdat <= '2018-11-09'

Anche se io dalla app. ottengo risultati migliori dei tuoi:
1 o 2 centesimi di sec per l'interrogazione giornaliera
e 14 o 9 secondi circa per circa 180000 a seconda che parta da appena aperto oppure che prima abbia fatto l'interrogazione giornaliera.

Tieni anche conto che nella tua applicazione il filtro non viene attivato all'apertura occorre impostarlo (vedi bug sopra).
  Vedo che non hai il modulo canberra come hai installato?

[Gianluigi]

Comunque se si fa questa semplice prova:

Codice: [Seleziona]

Public Sub Form_Open()

  With GridView1
    .Header = 3
    .Columns.Count = 4
    .Columns[0].Width = 60
    .Columns[0].Text = "ID"
    .Columns[1].Width = 120
    .Columns[1].Text = "Nome"
    .Columns[2].Width = 120
    .Columns[2].Text = "Cognome"
    .Columns[3].Text = "DATA"
  End With

End


Public Sub btnPopola_Click()

  Dim i As Integer
  Dim StartTime, DiffTime As Float

  StartTime = Timer
  For i = 0 To 179946
    GridView1.Rows.Count = i + 1
    GridView1[i, 0].Text = i + 1
    GridView1[i, 1].Text = "Daphne"
    GridView1[i, 2].Text = "Verdone"
    GridView1[i, 3].Text = "01/04/2018"
  Next
  DiffTime = Round(Timer - StartTime, -2)
  Message.Info(i & " record filtrati su 200.001 In " & DiffTime)

End

Si può constatare che ci mette più tempo del programma, la vedo dura ridurre i tempi...

[tornu]

In effetti se ci si limita ad interrogare DB Browser i risultati sono immediati 

179947 rows returned in 102ms from: SELECT *
FROM tuser
WHERE usdat >= '2009-11-09'
AND usdat <= '2018-11-09'

Che ne deduci?
Forse la visualizzazione dei dati non dipende solo dalla velocità di estrazione dal DB, anche se le sue impostazioni e la
costruzione delle query di interrogazione sono fondamentali. Codice Gambas e Gridview ?
Continuo a fare prove

Vedo che non hai il modulo canberra come hai installato?

Da repository PPA http://ppa.launchpad.net/gambas-team/gambas3/ubuntu bionic

[Picavbg]

Siete due grandi!
Oggi ho riflettuto su come revisionare le query di interrogazione delle tabelle di DB interessate, in modo da riunire la ricerca in un unica istruzione sql.
In aggiunta, siccome, per l'uso che ne faccio, la gridview di destinazione si compone di una 20 di righe, al massimo,  pensavo di raccogliere la risposta della nuova query in un array e trasferire, dopo, il contenuto di detto array nella gridview da mostrare nella form.
Mi direte che posso ulteriormente allungare i tempi, però se lo scaricamento dal DB è rallentato dalla costruzione della gridview, forse, separando lo scaricamento dalla costruzione e valorizzazione della gridview, il tempo complessivo d'esecuzione si potrà addirittura ridurre.
Dovrò verificare il tutto. Spero al più presto.