Newsgroup: it.comp.lang.visual-basic
Titolo: Help indicizzazione tabella

Ciao a tutti,
il mio programma VB va ad eseguire delle operazioni su di una tabella
storico così fatta:
  "CODFISC"  VARCHAR(16) NOT NULL,
  "NOMEDB"  VARCHAR(32),
  "DATAINIZIO"  DATE,
  "DATAFINE"  DATE,
  "IDR"  NUMERIC(10,0),
  "FILE3"  VARCHAR(32),
  "FILE4"  VARCHAR(32),
  "FILE5"  VARCHAR(32),
  "FILE6"  VARCHAR(32),
  "NPREST"  INTEGER,
  "ANNO"  VARCHAR(2),
  "DESCRIZIONE"  VARCHAR(50),
  "TIPOPREST"  VARCHAR(10)
Il CODFISC è indicizzato in quanto ci faccio delle operazioni dove la
velocità è buona. Ho però un routine che vorrei velocizzare che fa le
seguenti operazioni:
1)
SELECT * FROM STORICO WHERE UPPER(""TIPOPREST"")='x' AND
UPPER(""NOMEDB"")='x' AND UPPER(""ANNO"")='x' AND UPPER(""NPREST"")='x' ;"
2)
DELETE FROM STORICO WHERE ... (condizione WHERE come sopra)
3)
INSERT INTO STORICO (una sequenza di 1/5 record in media)
4)
UPDATE STORICO SET FILE3,FILE4,FILE5,FILE6 WHERE (condizione come le prime
due)
Le più lente sono le prime 2 operazioni che ci stanno tipo 7 secondi, mentre
le ultime due circa 2 secondi. I record della tabella sono circa 90.000.
Ho provato a fare un indice con TIPOPREST+NOMEDB+ANNO+NPREST ma non cambia
praticamente nulla.
Avete qualche consiglio?
Grazie :D
PS: non ho chiave, eventualemente se ci fosse sarebbero 4/5 campi insieme.

Andrea ha scritto:






Credo che il tuo collo di bottiglia risieda nelle UPPER che fai che
costringono il server a manipolare (in memoria) tutti i records per vedere
se entrano nella condizione where
Secondo me se risolvi eliminandola la questione dell'UPPER sei già sulla
via della soluzione
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 UPPER(""NOMEDB"")='x' AND UPPER(""ANNO"")='x' AND UPPER(""NPREST"")='x' ;"
access non consente 'upper'
upper = ucase ?
ciao, j.

 upper = ucase ?
Scusa hai ragione, il DB è interbase (.gdb) ed Upper sarebbe ucase :)

 sulla via della soluzione
Ho tolto le upper ma non cambia praticamente nulla, forse ci sta 6.5sec
invece di circa 7. :\
Invece adesso l'operazione 3 e 4 la fa in mezzo secondo, in quanto ho
l'update l'ho tolta e ho messo tutto nell'insert into.
In pratica ci stà 7+0.5 secondi.
Dovrei trovare il modo di migliorare quella select e quella delete.
Grazie :D

 Luciano wrote:


A questo punto rimetti in funzione l'indice che avevi provato, credo che
prima non funzionasse proprio perchè c'era la UPPER


 che prima non funzionasse proprio perchè c'era la UPPER
Bingo, ci sta 0.5 secondi adesso :)
Ti ringrazio.
PS: pensi ci potranno essere problemi quando la tabella avrà tipo 300/500
mila record?
Un indice su 4 campi può comportare altri problemi a livello di risorse
usate?
Grazie :)

 Luciano wrote:



Credo che qualsiasi database con centinaia di migliaia di record da
aggiornare tutti in una sola soluzione è naturale possa avere dei problemi.
Se il database gestisce bene gli indici l'unico problema che potresti
avere è lo spazio occupato che aumenta con l'aumentare dei
record/campi/indici.
Trasformare le query in stored procedure a cui passare dei parametri (a
parte il discorso sulla sicurezza) potrebbe rendere le tue elaborazioni
ancora più veloci
