Progettazione e prestazioni dei database (SQL Server Compact)
È possibile migliorare significativamente le prestazioni dell'applicazione SQL Server Compact 4.0 progettando correttamente il database e la pubblicazione di SQL Server. Nelle sezioni seguenti vengono illustrate le tecniche disponibili per l'ottimizzazione delle prestazioni.
Utilizzare la denormalizzazione del database
Un database normalizzato impedisce dipendenze funzionali nei dati, in modo da garantire un aggiornamento semplice ed efficiente del database. L'esecuzione di query sul database, tuttavia, può richiedere numerosi join di tabelle per combinare le informazioni. Con l'aumento del numero di tabelle di join, il tempo di esecuzione della query subisce un incremento significativo. Pertanto, un database normalizzato potrebbe non rappresentare sempre la soluzione ottimale. Un database con la quantità appropriata di denormalizzazione riduce il numero di tabelle da unire in join, senza rendere eccessivamente complicato il processo di aggiornamento. Si tratta in genere di un compromesso efficiente.
Nota
In generale, se un numero significativo di query richiede il join di più di cinque o sei tabelle, è consigliabile considerare la denormalizzazione.
Sono inoltre disponibili altri tipi di denormalizzazione dei database. Si supponga ad esempio di disporre di due tabelle di un database: Orders e Order Details. La tabella Orders contiene informazioni sull'ordine di un cliente. I singoli prodotti di ogni ordine sono inclusi nella tabella Order Details. Si supponga di dover eseguire una query sull'importo totale in dollari di ogni ordine. È innanzitutto necessario determinare l'importo in dollari per ogni prodotto (unità * prezzo unitario – sconto applicabile). Successivamente, si devono raggruppare gli importi per ordine. La query assumerà l'aspetto seguente:
SELECT "Order ID", SUM("Unit Price" * Quantity * (1.0 - Discount))
AS Total FROM "Order Details"
GROUP BY "Order ID"
Order ID Total
----------------------------------------
10000 108
10001 1363.15000915527
10002 731.800003051758
10003 498.180023193359
10004 3194.19999694824
10005 173.400009155273
10006 87.2000007629395
10007 1405
10008 1171
10009 1530
10010 470
... ...
(1078 rows affected)
Il calcolo per questa query è considerevole. Per un set esteso di ordini, l'esecuzione della query può richiedere una notevole quantità di tempo. L'alternativa consiste nel calcolare l'importo in dollari dell'ordine al momento del relativo inserimento e quindi archiviare tale importo in una colonna all'interno della tabella Orders. Con questo approccio, per restituire le informazioni necessarie è sufficiente eseguire la query sulla colonna pre-calcolata:
SELECT "Order ID", "Order Total" AS Total FROM Orders
Creando una colonna pre-calcolata, è possibile risparmiare tempo in relazione alla query, ma questo approccio richiede il mantenimento di una colonna aggiuntiva nella tabella.
Scegliere tra colonne a lunghezza variabile e fissa
In occasione della progettazione di tabelle, è opportuno comprendere i compromessi associati all'utilizzo di colonne a lunghezza variabile e di colonne a lunghezza fissa. Le colonne a lunghezza variabile riducono le dimensioni del database, poiché richiedono soltanto lo spazio necessario per l'archiviazione del valore effettivo. Le colonne a lunghezza fissa occupano sempre lo spazio massimo definito dallo schema, anche se il valore effettivo è vuoto. Lo svantaggio delle colonne a lunghezza variabile consiste nel fatto che alcune operazioni risultano meno efficienti rispetto a quelle con colonne a lunghezza fissa. Se una colonna a lunghezza variabile inizialmente di dimensioni ridotte viene espansa notevolmente con un aggiornamento, potrebbe essere necessario rilocare il record. Aggiornamenti frequenti, inoltre, determinano nel tempo una maggiore frammentazione delle pagine di dati. È pertanto consigliabile utilizzare colonne a lunghezza fissa quando le lunghezze dei dati non subiscono eccessive variazioni e quando vengono eseguiti aggiornamenti frequenti.
Creare lunghezze di riga ridotte
Il numero di righe che può essere contenuto in una pagina dipende dalla compattezza di ogni riga. In presenza di righe di dimensioni ridotte, una pagina può contenere più righe. Pertanto, una singola operazione su disco relativa a una tabella con righe compatte può recuperare un maggior numero di righe e risultare così più efficiente. Nella cache del motore di archiviazione, inoltre, possono essere contenute più righe, migliorando potenzialmente la frequenza di accesso. Righe compatte impediscono inoltre lo spreco di spazio nelle pagine di dati, comune nel caso di righe di maggiori dimensioni.
Si consideri l'esempio estremo di record di dimensioni leggermente superiori alla metà di una pagina di dati. In questo caso, quasi la metà dello spazio di ogni pagina di dati risulta inutilizzato. Alcuni progettisti di database optano per una progettazione estesa delle tabelle ed eseguono il porting dello schema di database per mainframe sul dispositivo. Questa progettazione potrebbe rivelarsi non efficiente. Un approccio possibile consiste nel suddividere le tabelle più critiche. Si supponga di disporre di una tabella con alcune colonne con valori molto stabili e altre che vengono modificate frequentemente. È opportuno suddividere la tabella in due: una con le colonne con riferimenti frequenti e l'altra con le colonne stabili. Creando due tabelle, è possibile usufruire di tutti i vantaggi di una lunghezza di riga ridotta. Il compromesso consiste nel fatto che per combinare le informazioni è necessario un join.
Utilizzare lunghezze di chiave ridotte
Un indice è un subset ordinato della tabella su cui viene creato e velocizza la ricerca in intervalli e l'ordinamento. Chiavi di indice ridotte occupano meno spazio e offrono una maggiore efficienza rispetto a chiavi di maggiori dimensioni. In particolare, è opportuno utilizzare una chiave primaria compatta poiché vi viene spesso fatto riferimento come chiave esterna in altre tabelle. Se non è disponibile una chiave primaria compatta naturale, è possibile utilizzare una colonna Identity implementata come Integer.
Un indice con una o poche colonne chiave viene denominato indice limitato. Un indice con numerose colonne chiave viene denominato indice esteso. Un indice esteso è in genere associato a una lunghezza di chiave elevata. Un esempio estremo è costituito da un indice che include ogni colonna della tabella. Creando un indice di questo tipo, è possibile creare un duplicato della tabella originale. Questo si rivela tuttavia inefficiente in termini sia di dimensioni del database che di prestazioni delle query.
Vedere anche
Concetti
Ottimizzazione delle prestazioni delle query (SQL Server Compact)