Query multi-step

di il
16 risposte

Query multi-step

Spesso nell'aggregazione dei dati da fornire all'utente, come conseguenza della normalizzazione dei dati, bisogna interrogare più tabelle e non sempre è conveniente farlo con un'unica query. Occorre quindi eseguire le query per step, salvandone il risultato perché venga eventualmente utilizzato nella query successiva. Un metodo è sicuramente quello di usare una o più tabelle temporanee, vorrei pero' sapere se esistono metodi più efficienti. Ogni considerazione o anche semplicemente chiave di ricerca è ben accetta.

16 Risposte

  • Re: Query multi-step

    MonkeyH ha scritto:


    ... non sempre è conveniente farlo con un'unica query ...
    Piu' che non sempre dovresti dire abbastanza raramente.

    Spezzare una query in sottoquery da salvare in tabelle temporanee implica forzare il DBMS a non utilizzare in modo intelligente gli indici presenti nelle tabelle, ma obbligarlo a fare un FULL SCAN sulle tabelle temporanee.

    Per quanto la query possa essere complicata, se i dati sono normalizzati in modo corretto, sono stati creati gli indici in modo intelligente, e la query e' stata espressa in modo non troppo arzigogolato, il QUERY PLAN e' in grado di ottimizzarla in modo da ottenere il risultato nel modo piu' efficiente possibile, e sfruttare al meglio gli indici disponibili.

    Quindi, la regola e':

    1) mai spezzare una query in sottoquery, mai utilizzare tabelle temporanee
    2) ma se lo devi proprio fare, per N-mila motivi, assicurati che le tabelle temporanee siano decisamente piccole (con pochi record).
  • Re: Query multi-step

    Capisco che sia possibile comporre il dato finale chiamando in cascata tutte query necessarie e ogni volta che sia necessario. Vorrei sapere però se a livello teorico, eseguire n volte una query che restituisce 1 record su 50000 esaminati, sia più efficiente che storicizzare il risultato in una tabella temporanea.
  • Re: Query multi-step

    Da quello che so, quando salvi la query, access analizza quello che vuoi fare e poi decide lui quale sia la strada migliore da seguire per avere il massimo risultato sia in termini prestazionali che gestionali.

    Potrebbe decidere esso stesso di dividere, indicizzare, non indicizzare, appoggiarsi a tabelle virtuali etc etc. per eseguire, non la tua query, ma quello che vuoi fare con la query.

    per ottimizzare al massimo, bisognerebbe sapere esattamente come funziona access e sopratutto sapere che strada sceglie.

    Dividere in sottoquery o tabelle, andresti a forzare il sistema.
    Certo. scrivere una query ottimizzata sicuramente aiuta.
    A me è stato spiegato in questa maniera, poi non so se effettivamente è così.
  • Re: Query multi-step

    La cosa è molto più semplice di quanto possa sembrare, e l'ha spegata molto chiaramente [migliorabile]... qualsiasi TEMP TABLE che non relaziona ed ottimizza gli INDICI è una cosa "discutibile"... a prescindere da come il Motore del DB lavora... Tabelle singole NON RELAZIONATE non fanno parte di nessun processo di ottimizzazione, obbligando il motore al FULLSCAN e nessun sviluppatore o progettista di DB fa queste cose, se non come già suggerito su Tabelle di pochissimi RECORDS...
  • Re: Query multi-step

    Avere tabelle temporanee con pochissimi record non è un'esigenza tanto rara se consideriamo ad esempio le query che devono popolare una maschera: ci si aspetta che la quantità di record gestibili da un utente, in una consultazione, sia irrilevante rispetto alla mole di dati da cui si attinge.
    Mi riferisco all'esempio postato nel thread precedente:

    http://www.iprogrammatori.it/forum-programmazione/access/sql-complesse-vba-t24158.html#p8535073

    E' sempre preferibile la soluzione della query unica rispetto alle tabelle temporanee, quindi anche in questi casi?
  • Re: Query multi-step

    La tua domanda è strana...
    Un RDBMS che ha 1 Tabella con 1.000.000 di Records, se lo interroghi con la Clausola WHERE non genera traffico dati per 1.000.000 di Records, ma solo quello per soddisfare la WHERE condition.

    Fai attenzione che parlavo di un RDBMS... non di Access(JET) che lavora in LOCALE quindi tutt'altro discorso... tuttavia sono considerazioni molto superficiali fatte così a spot...
  • Re: Query multi-step

    Perdonami ma fatico a seguirti...
    Mi spiego meglio:
    Se ho una select su 1.000.000 di record che restituisce es. 10 record, e il risultato di questa query mi serve in altre 5 query, ha senso far eseguire la select 5 volte anziché salvare il risultato in una tabella temporanea?
    Non parlo di traffico di dati: anche se ne vengono restituiti solo 10, ne vengono, in qualche modo, elaborati 1.000.000.
    Per quanto ne posso capire, molto sommariamente i casi sono tre:
    - l'RDBMS ha un sistema di ottimizzazione che rende superfluo il salvataggio, perché se lo fa da solo ed in modo più efficiente.
    - Una select complessa su 1.000.000 record indicizzati è comunque più veloce, o non è più lenta, di una select semplice su 10 record in una tabella non indicizzata e non relazionata.
    - in casi come questo ha senso salvare su una tabella temporanea.
    Se mi sfugge qualcosa, perdonami.
  • Re: Query multi-step

    Non voglio sembrare il disfattista della discussione. Ben vengano discorsi puramente filosofici nei thread del forum, ma ritengo che è sempre meglio parlare di cose concrete (nomi tabelle, nomi di campi, relazioni...) per comprendere le query successive.
    Potrebbe pure accadere che tu MonkeyH hai aperto questo thread perché sai di cosa stai parlando, ma gli altri utenti, in mancanza di elementi concreti, possono solo immaginare.
    Concordo anch'io sulla risposta efficace di migliorabile.
  • Re: Query multi-step

    OsvaldoLaviosa ha scritto:


    Non voglio sembrare il disfattista della discussione. Ben vengano discorsi puramente filosofici nei thread del forum, ma ritengo che è sempre meglio parlare di cose concrete (nomi tabelle, nomi di campi, relazioni...) per comprendere le query successive.
    Potrebbe pure accadere che tu MonkeyH hai aperto questo thread perché sai di cosa stai parlando, ma gli altri utenti, in mancanza di elementi concreti, possono solo immaginare.
    Concordo anch'io sulla risposta efficace di migliorabile.
    Al contrario, credo... La risposta di migliorabile è ineccepibile, ma è un po' dogmatica. Mi chiedevo se proprio nel caso specifico che ho descritto più sopra (c'è anche un link con la query) fosse comunque la strada da seguire.
  • Re: Query multi-step

    Io sostengo che senza basi tecniche di teoria si parla di aria fritta... quindi non volendo insistere con ulteriori dettagli, ti è stato chiarito pienamente il concetto, ora ti suggerirei di prenderti un libro serio di come si strutturano ed ottimizzano a livello prestazionale, i database...
    Sono in inglese da 1000 e rotte pagine ma servono.
    Quando abbiamo una base di teoria solida, possiamo superare la discussione basata sulla semplice contrapposizione di idee, e parlare la stessa lingua tecnica concretamente.
  • Re: Query multi-step

    Ciao alex, potresti darmi i link (se disponibili on line) che approfondiscono il concetto?

    Grazie.
  • Re: Query multi-step

    Alex, di tutto quello che è stato scritto, le uniche cose che non comprendo sono le tue ultime risposte... fatico a capire se la contrapposizione di idee rispetto al parlare lo stesso linguaggio tecnico sia un bene o un male... non lo so. Non ho mai parlato di aria fritta e non è mia abitudine farlo. Ho posto un esempio concreto ma ho detto che mi serviva per generalizzare. Perché la discussione servisse anche ad altri e non solo a me. Non era mia intenzione fornire opinioni personali, se non con l'unico scopo di esprimere un dubbio, fare domande e fornire un pretesto, a chi ne avesse voglia, di sviscerare un argomento.
    Capisco però che l'argomento affrontato può essere piuttosto complesso e se non lo si padroneggia completamente, c'è il rischio che si possa finire davvero col dare opinioni campate in aria. Ma, ti assicuro, non sarebbe stato per causa mia.

    Comunque, come hai scritto, il concetto mi sembra chiaro e tanto basta: nessuno usa le tabelle temporanee.
    Vi ringrazio per la discussione.
  • Re: Query multi-step

    @MonkeyH, piu' che dogmatica, direi assiomatica
    Sei sicuro che non ci sia una soluzione piu' intelligente, dove, invece di forzare il sistema, lo agevoli?

    Ad esempio, mai preso in considerazione l'uso di specifiche view?
    O di tabelle di servizio (che non sono tabelle temporanee, ma normali tabelle con tanto di indici) popolate automaticamente da trigger?

    Comunque, il modo di affrontare qualunque problema e' sempre lo stesso: prima si studia la materia. E la materia, in questo caso, e' la teoria relazionale dei dati.

    Poi, si cerca di trovare una soluzione intelligente al problema in questione.
    Dai post ho notato che si e' passati da

    1) una query complessa scomposta in sottoquery e tabelle temporanee

    a

    2) una query che ritorna un piccolo numero di record (1) usata in diverse altre query.

    Puoi ben capire che non esiste la risposta definitiva, ma solo delle regole generali che uno dovrebbe seguire in mancanza di una dimostrazione contraria.

    E la dimostrazione la si ottiene facendo dei test (e non su 10 record, dove qualunque soluzione va bene, ma su 10.000/1.000.000, o piu'), da cui risulti che una soluzione e' il 10/50/90% piu' efficiente dell'altra.
  • Re: Query multi-step

    MonkeyH ha scritto:


    Alex, di tutto quello che è stato scritto, le uniche cose che non comprendo sono le tue ultime risposte... fatico a capire se la contrapposizione di idee rispetto al parlare lo stesso linguaggio tecnico sia un bene o un male... non lo so. Non ho mai parlato di aria fritta e non è mia abitudine farlo. Ho posto un esempio concreto ma ho detto che mi serviva per generalizzare. Perché la discussione servisse anche ad altri e non solo a me. Non era mia intenzione fornire opinioni personali, se non con l'unico scopo di esprimere un dubbio, fare domande e fornire un pretesto, a chi ne avesse voglia, di sviscerare un argomento.
    Capisco però che l'argomento affrontato può essere piuttosto complesso e se non lo si padroneggia completamente, c'è il rischio che si possa finire davvero col dare opinioni campate in aria. Ma, ti assicuro, non sarebbe stato per causa mia.

    Comunque, come hai scritto, il concetto mi sembra chiaro e tanto basta: nessuno usa le tabelle temporanee.
    Vi ringrazio per la discussione.
    Siccome ho visto che, nonostante ti fossero state date indicazioni tecnice con un certo indirizzo, hai più volte puntualizzato i dubbi originali come se non fosse stato compreso il concetto tecnico esposto... ho pensato che probabilmente l'allineamento dei concetti base, che è fondamentale per comprendersi, forse potrebbe essere perfettibile...
    Il senso è che io non voglio insistere nè devo convincerti, spero tuttavia che ti si possa sviluppare il dubbio che riesca a spingerti all'approfondimento con la dovuta criticità di valutazione.

    Questi sono ottimi libri:
    http://www.amazon.com/dp/0321197844/?tag=stackoverfl08-20
    http://www.amazon.com/dp/0321497643/?tag=stackoverfl08-20
    http://www.amazon.com/dp/0073523321/?tag=stackoverfl08-20
Devi accedere o registrarti per scrivere nel forum
16 risposte