Unioni tra database

Question

I dati del mio datamart di magazzino sono suddivisi in 3 database sullo stesso server. Questo è il progetto Proof-Of-Concept con tre estratti che sono stati caricati in singoli database.

Mentre sto tirando dentro un cubo, essenzialmente sto facendo questo:

SELECT * FROM DB1.dbo.Fact_Pres
UNION
SELECT * FROM DB2.dbo.Fact_Pres
UNION
SELECT * FROM DB3.dbo.Fact_Pres

Dovrei effettivamente consolidare i dati in UNA tabella? Questo renderà la mia elaborazione più veloce?

Non ho problemi con lo spazio su disco: voglio implementare la soluzione migliore.

In entrambi i casi, puoi aiutarmi a capire perché il metodo che suggerisci sarebbe ottimale?

Answer 1

La query tra database è (un po ') più lenta di quella nel database, se hai bisogno di tre tabelle separate, è consigliabile usare schemi diversi all'interno dello stesso db. Se si tratta di una tabella fattuale, è consigliabile caricarla in una tabella fattuale singola e utilizzare il partizionamento se la dimensione è troppo grande.

Quando si tratta di ETL, il suggerimento è di ETL in tabelle di gestione temporanea in uno schema separato - come ETL - all'interno dello stesso DB e caricare la tabella dei fatti da lì. Al termine, si troncano le tabelle di gestione temporanea.

Le raccomandazioni sono tratte dal Microsoft Project Real .

Tieni inoltre presente che la chiave esterna non può essere utilizzata nei database.

Answer 2

Valuta di federare la tua tabella usando il partizionamento di prima classe di SQL Server (invece di farlo da solo). Se selezioni sempre ogni punto dati, forse sì, estrarre più dischi è più veloce.

Ma perché avere più database? È sempre possibile impilare le tre tabelle in una tabella, ma tale tabella deve essere implementata su tre unità RAID insieme. Questa è una soluzione più chiara se ciò che cerchi è la velocità.

La federazione ha senso solo se selezioni parti adiacenti specifiche dell'insieme. Ma secondo il tuo PO, stai selezionando tutto, in modo da eliminare quel vantaggio.

Answer 3

Sì, dovresti assolutamente. Non ha senso dividere la stessa tabella in database diversi. Se hai problemi con lo spazio sul disco rigido, pensa a partizionare la tabella.

Per quanto riguarda il tuo commento:

Il costo della performance non è COSÌ enorme, ma un'unione esegue un join di unione, il che comporta un po 'di spese generali.

Inoltre, sei sicuro di utilizzare UNION correttamente? UNION eliminerà i valori duplicati. Forse quello che vuoi davvero fare è UNION ALL?

Answer 4

Un UNION esegue essenzialmente un seleziona distinto in modo che possa rimuovere i record duplicati. Ciò (potenzialmente) comprometterà le prestazioni da solo. Puoi rettificarlo modificandolo in UNION ALL .

Oltre a ciò, dovresti controllare il piano di esecuzione per vedere che tipo di prestazioni ha colpito. So che SQL Server utilizzerà gli indici anche su tabelle in altri database, ma ciò che stai facendo qui non ha molto senso. Suggerirei di utilizzare il partizionamento delle tabelle e di tenerlo tutto in un database se lo scenario di utilizzo normale è UNIONE tutte le tabelle insieme, ci sono poche buone ragioni per separarle in database diversi.