Importare dati da sql in power query: meglio una vista o tabelle separate L’argomento è risolto

[Alex63]

Buongiorno a tutti una nuova domanda per voi: per alimentare una power pivot qual'è, secondo voi, la strada più corretta:

1 creare una vista su sql con i dati già pronti o importare le singole tabelle e poi collegarle in gestione modello dati o power query?

2 Ipotizzando di aver creato una vista su sql (query di unione) tra due viste (si parla sempre di dati di vendita), vi risulta che ci sia un limite di nr campi importabili su power query? Ve lo chiedo perchè ho una situazione dove ho aggiunto un nuovo campo su due viste che alimentano la union, ma questo nuovo non viene importato in power pivot esistenti, neppure creando una power query ex novo, avete qualche suggerimento?
Grazie per l'attenzione.

[Enrico Galli]

Ciao Alex63 , allora:

1) premesso che, potendo, dal punto di vista prestazionale è sempre meglio fare lavorare il server di database piuttosto che la macchina locale per le operazioni di ETL, ci sono varie considerazioni da fare: se tu importi una vista già elaborata, con JOIN e tutto quanto, avrai una tabella monolitica; se importi i vari componenti di uno schema a stella, avrai invece un modello di dati vero e proprio. Tutto dipende dalle analisi da fare: spesso le tabelle che io ho definito "monolitiche", che quindi contengono tutti i campi al loro interno, magari introducendo una replicazione dei dati su più righe, sono difficili da utilizzare e possono richiedere del codice DAX complicato anche per semplici indicatori. Altre volte non è così.
In generale, il consiglio è sempre quello di utilizzare un modello a stella in Power Pivot, per garantire la massima flessibilità di analisi.

2) Non c'è un limite fisico di colonne importabili, e il problema che descrivi è molto strano: non è che la colonna viene effettivamente importata, ma poi in un passaggio successivo della query viene scartata?

[Alex63]

Ciao Enrico, per il punto uno chiara la risposta, mentre per il punto 2 anche io non riesco a capire il motivo della mancanza del campo.
Nelle due singole viste il campo è stato aggiunto (stessa posizione) e lo vedo se lancio una select delle singole viste mentre se lancio una select della union (vedi sotto) il campo non è presente.

Codice: Seleziona tutto

SELECT *
FROM [dbo].[SPEDIZIONE] AS s
WHERE s.[QtaSpeditaNonFatturata] > 0
UNION ALL
SELECT *
FROM [dbo].[FATTURA]

[Alex63]

Scusa rettifico fino alla union il campo è presente, lo perdo nella creazione della power query

[Enrico Galli]

Mi spiace, ma oltre a quello che ho già ipotizzato, altro non riesco a dirti. Puoi almeno mettere il codice della query, così capiamo se c'è qualche inghippo?

[Alex63]

Queste sono le tre viste usate per alimentare la base dati.

[Enrico Galli]

Scusa, mi sono spiegato male. Intendevo il codice della Query di Power Query, non l'SQL

[Alex63]

Intendi questo:

let
Origine = Sql.Database("dbserver", "newfactor_bi"),
dbo_Vendite_Statistiche = Origine{[Schema="dbo",Item="Vendite_Statistiche"]}[Data]
in
dbo_Vendite_Statistiche

[Lodovico D'Incau]

Ciao Alex63,
ti riporto la mia esperienza personale, considera che lavoro con centinaia di persone e tabelle che vanno dai 10.000 record ai 300 mln, quindi da qui le mie considerazioni.. allora:

1) Quoto Enrico quando scrive che tendenzialmente è più corretto far lavorare il SQL, ma fai attenzione a una cosa molto importante:
- Il costo delle licenze di SQL è relativo al numero di processori che hai installati sulla macchina.
- Quindi se il tuo foglio di excel lavora su un'altra macchina come penso, utilizzare le risorse di una macchina esterna, se possibile, è meglio, in quanto andrai a risparmiare soldini in possibili costosi upgrade al SQL.
- Ciò nonostante se ti trovi in una condizione di possibilità hardware che può supportare senza problemi quel che stai facendo, oppure lavorare in SQL ti da poi un beneficio comune a n report esterni allora l'ETL fallo ad occhi chiusi in SQL, è sicuramente migliore di PowerQuery "anche se meno intuitivo nello sviluppo".

2) Vedo che usi un driver OLEDB, li usavo anche io un tempo, te li sconsiglio, vai di driver ODBC versione 13 o 17.
- Sono più veloci
- Se un domani cambi nome all'istanza con il driver ODBC ti basterà ripuntare lui (al contrario con l'OLEDB ti tocca ripassarti tutte le query di tutti i report)

3) A mio avviso il flusso ottimale è sempre questo
- SQL => PowerQuery => PowerPivot
- Questo a prescindere che tu faccia trasformazioni o no in PowerQuery, dalle esperienze che ho avuto, il flusso così costruito risulta più stabile e non ti precludi mai la possibilità di fare qualche accortezza in PowerQuery in un futuro (da non escludere mai).

4) In riferimento al tuo problema specifico, se ho ben inteso quel che sta succedendo è una furbata di SQL...
- Quando modifichi una Tabella oppure una View, le View che leggono da queste sorgenti devono essere rigenerate anche se l'ultima View fa un Select *
- La memoria del Select * è sempre popolata con il set di campi presente prima della tua ultima modifica, quindi per far comparire il nuovo campo devi rinfrescare la cache della View..
- Quindi fai un bel ALTER alla View finale e poi fai ESEGUI, così facendo dovrebbe poi funzionare

Per il punto 4 se non funziona o ho capito male il problema fai sapere..
A presto

[Alex63]

Vi ringrazio per i preziosi consigli vi farò sapere se il problema del punto 4 si risolve.
State facendo un grande lavoro di divulgazione..