Query complessa

di il
6 risposte

Query complessa

Ciao a tutti, utilizzo postgresql ed ho questo problema.
Ho una vista che rappresenta gli ordini presenti in archivio con n colonne.
Avrei la necessita di estrarre il conteggio degli ordini dell'anno/anni passati come parametro raggruppati per anno e mese. Questo non è un problema, il problema è che io vorrei una tabella in output con questo formato (se per esempio passo gli anni 2023 e 2022):

Mese - Anno - Ordini - Anno - Ordini
01         2023    10          2022    25
02         2023     5           2022    12
.
.
.

Grazie

6 Risposte

  • Re: Query complessa

    Devi fare una cosa di questo tipo: ti server una select e due subselect.

    con ogni subselect selezioni gli ordini raggruppati per mese per l'anno di interesse

    con la select principale crei il join tra le due subselect. ATTENTO the devi fare una OUTER JOIN, NON una INNER JOIN, perche' se un mese non e' presente in un anno MA presente nell'altro, DEVE essere generata la corrispondete riga.

    COMUNQUE la soluzione NON VA BENE. Ti serve anche assicurarti che se non ci sono ordini in uno o piu' mesi, in ENTRAMBE le tabelle, ci deve essere la corrispondete riga con scritto 0. 

    Questo complica abbastanza la corrispondente query. 

    Direi che sarebbe meglio creare una ‘stored procedure’

    https://www.postgresql.org/docs/current/sql-createprocedure.html 

    https://www.postgresql.org/docs/current/xplang.html 

    .

  • Re: Query complessa

    Grazie per la dritta, secondo te come è meglio procedere per ottenere ciò che mi serve considerando che l'utente potrebbe selezionare 1,2,3,n anni?

    Grazie

  • Re: Query complessa

    Stored Procedure, perche' L'SQL non permette di fare cose del genere: non e' un linguaggio di programmazione ‘di uso generale’ , ma un linguaggio di interrogazione super specializzato su una particolare paradigma di rappresentazione dei dati.

    mentre la stored procedure si appoggia ad un linguaggio di programmazione general purpose. 

    Comunque potrebbe anche valere la pena fare tutto lato client, tanto quel n non sarà un milione, ma, a stima (ma lo sai solo tu) meno di 20. Ed eviti di diventare matto con le SP. Con 20, devi ricuperare al massimo 240 record, un'inezia, un microbo, una pulce,… (battuta da ‘Dave - presidente per un giorno’ ;-) ) 

  • Re: Query complessa

    Le stored procedure le conosco, le ho già usate anche in sql server. La mia richiesta era una traccia, un'idea su come meglio strutturarla logicamente tutto qui :)

    In effetti l'utente a stima potrebbe selezionare al massimo 3-4 anni per avere un confronto sull'andamento degli ordini, forse gestire il tutto lato client è la soluzione migliore che dici?

    Grazie ancora

  • Re: Query complessa

    Una soluzione vale l'altra. Quello che ti e' piu' semplice implementare.
    Gli oggetti coinvolti sono troppo pochi per dire ‘la soluzione A e’ significativamente meglio/peggio di B'. 

    E' come dire se un millisecondo e' meglio o peggio di un millisecondo  mezzo. 
    Solo che questa differenza viene annegata in un'applicazione che, come funzionamento, richiede secondi.
    Assolutamente ininfluente.

  • Re: Query complessa

    Grazie comunque della preziosa indicazione sull'utilizzo del JOIN tra SELECT, non avevo ancora avuto necessità di utilizzare questa possibilità.

Devi accedere o registrarti per scrivere nel forum
6 risposte