Ottimizzazione stringa SQL

di il
4 risposte

Ottimizzazione stringa SQL

'
  sSql = "SELECT htype, (SELECT SUM(amt) FROM REGISTRY WHERE htype = 0 AND hacct = " & hacct & ") AS Dare,(SELECT SUM(amt) FROM REGISTRY WHERE htype = 1 AND hacct = " & hacct & ") as Avere FROM REGISTRY"
        '
Buongiorno, per favore chiedo se si puo' ottimizzare questa stringa,anche se funziona cosi' com'e'.
Io sviluppo con VB.NET 2015 Enterprise.
'
Serve a visualizzare il saldo per ogni conto ( hacct), mentre htype e' il tipo di conto ( 0=Entrata 1=Uscita 2=Trasferimento) e amt e' l'importo che diventa positivo o negativo in base a htype.

4 Risposte

  • Re: Ottimizzazione stringa SQL

    Hai uguaglianze, quindi ti serviranno indici sui campi relativi, ovviamente se la selettività degli stessi è elevata.
    Altrimenti tabelle di supporto coi totali aggiornati es da trigger
  • Re: Ottimizzazione stringa SQL

    Salve,
    beh.... di base vedo alcune cosine che "non mi piacciono"
    - innanzitutto la concatenazione di stringhe per passare un "parametro", e questo ti puo' eventualmente causare seri problemi di sql injection....
    - poi non comprendo bene l'uso della subquery interna...
    se ho ben compreso la tua necessita', avrei fatto una rotazione orizzontale su colonna tramite CASE WHEN ... in base a [htype] e [hact] per avere una sola espressione...
    -- vedo che referenzi gli oggetti a livello di Tabella/Vista senza specificare lo "schema" di appartenenza, quindi utilizzi chiamate non FULL QUALIFIED. Questo NON permette all'optimizer di SQL Server di riutilizzare il piano di esecuzione della query, che verra' sempre ricompilata ad ogni successiva esecuzione, sprecando quindi molte risorse sia a livello di memoria, di IO, che di mero tempo di esecuzione finale... considera che il tokenizer deve in questo caso anche verificare nell'intero catalogo per tutti gli schemi quale sia l'oggetto referenziato (magari duplicato, e questo sarebbe l'unico caso corretto di non utilizzo di non qualificare completamente l'oggetto) disponibile nelle autorizzazioni dell'esecutore della query...

    quindi, brutalmente, utilizzerei innanzitutto un oggetto Command per caricare il parametro di @hact, e trivialmente riscriverei il tutto in
    
    Dim sql as String = "SELECT r.[htype]" _ 
                        ", SUM( CASE r.[htype] WHEN 0 THEN r.[amt] ELSE 0.00 END ) AS [Dare]" _
                        ", SUM( CASE r.[htype] WHEN 1 THEN r.[amt] ELSE 0.00 END ) AS [Avere]" _
                        "FROM [nome_dello_schema].[REGISTRY] r" _
                        "WHERE r.[hact] = @hact"
    
    al di la' di cio', non conoscendo pero' la struttra della base dati, non vedo un filtro di WHERE particolarmente stringente, e la cardinalita' del risultato dovrebbe essere a mio avviso molto alta....

    - ultima, ma non ultima, personalmente non amo molto di codice dinamico, sia esso costruito a mano o generato dagli orm... preferisco di gran lunga la chiamata a stored procedure, dove il dba, a conoscenza delle richieste specifiche in quanto probabilmente scrive le query lui stesso, puo' eventualmente affinare ed agevolare l'esecuzione delle query generando indici, statistiche, hint di esecuzione, .... ma capisco che questa affermazione possa anche scatenera flame e guerre di religione, quindi mi fermo


    EDIT: scutate, per tutta la parte di qualification ho dato per scontato l'utilizzo di SQL Server, ma ovviamente questo puo' non essere il tuo caso, quindi chiedo venia

    saluti
    --
    Andrea
  • Re: Ottimizzazione stringa SQL

    @karlettogd:
    Come mai hai usato due sub-query?
    Manca la condizione WHERE, quindi la tua query mostrerà tutti le righe mostrando lo stesso Dare e Avere per tutti i record. Che senso ha?

    Inoltre devi specificare il tipo di database che stai usando, per poter dare suggerimenti mirati.
    Infine, sarebbero utili una serie di dati (record) della tua tabella.
  • Re: Ottimizzazione stringa SQL

    Salve,
    mi correggo anche io, che MI sono tratto in inganno da solo, come gibra...
    il filtro di WHERE puo' tranquillamente essere giusto che NON sia troppo limitante, e la cardinalita' sara' probabilmente alta, ma trattandosi di un'aggregazione puo' avere senso...
    scusa @karlettogd, cosi' imparo a leggere meglio, ma per il resto dei miei commenti resto del medesimo avviso...
    sautissimi e augurissimi omnia
    --
    Andrea
Devi accedere o registrarti per scrivere nel forum
4 risposte