SQL Server - Svantaggi sulle prestazioni/dimensioni delle colonne Null

Question

Sto lavorando a un progetto di tabella che potrebbe comportare molti valori NULL in circa 10 campi, forse il 75% del tempo in cui i campi non saranno utilizzati.

Ho appena generato alcuni dati falsi (un milione di record) e non è stato possibile rilevare alcun impatto su SQL Server 2005. La differenza di dimensioni era nel KB. Prestazioni: nessuna differenza misurabile dopo l'aggiunta di un indice alle 3 colonne non annullabili.

So che SQL Server 2008 ha la funzionalità di colonne sparse (che presumo verrà utilizzata nella successiva tabella UserData di SharePoint). Voglio che il mio codice funzioni sul 2005 però. Ma molti valori NULL esistono nella progettazione della tabella UserData SharePoint corrente. Quindi se è abbastanza buono per Microsoft ...

Eventuali buoni articoli, collegamenti, white paper sugli inconvenienti o punti dolorosi attorno a molti valori NULL nella tabella di SQL Server? Qualcuno ha esperienza su ciò che accade mentre ridimensionate fino a 10 mil o 100 mil di record?

Answer 1

Non ho mai avuto problemi con le prestazioni su più colonne nulle, anche su database in dimensioni di centinaia di gigs. Immagino che tu possa finire con problemi se stai facendo funzionare indici su questi campi e poi usando null nella query, ma non ho visto questo come un problema personale. Poi di nuovo, non ho creato tabelle di database in cui ogni campo tranne 3 era nullable.

D'altra parte, vedo un problema di architettura quando la maggior parte dei dati è nullo. la ragione generale è a) un database normalizzato in modo errato o b) un tentativo di consentire agli utenti di mettere in scena i dati nella tabella finale piuttosto che creare tabelle separate per "costruire" i dati prima di impegnarsi nel database.

Sta a te determinare la migliore architettura del tuo database.

Answer 2

Non creare una tabella con colonne non utilizzate del 75%. Fallo con le colonne che utilizzerai sempre e dai un'occhiata a qualcosa come EAV per le altre colonne o mettile in una tabella diversa.

Answer 3

I problemi che ho avuto in passato riguardano le implicazioni di programmazione di avere valori NULL. Ad esempio, problemi con i client o problemi con non nelle query che restituiscono dati quando non sono previsti perché c'era un valore nullo.

Answer 4

Bene, NULL è sempre un po 'strano nei database. Non penso che abbia un impatto sulle prestazioni nel tuo caso, ma ovviamente dovrai gestire tutti i valori NULL separatamente.

Quando possibile, mi sforzo di utilizzare un valore predefinito, quindi, se si dispone di es. qualche valore ID di tipo INT, potresti usare 0 o -1 come indicatore "nessun valore presente". In tal modo, è possibile evitare di dover verificare il valore (campo < 0) e verificare separatamente NULL (campo IS NULL o IS NOT NULL).

Marc

Answer 5

C'è solo un modo per essere sicuri. Vai avanti e inserisci 100 milioni di record, quindi misura le prestazioni end-to-end.

Answer 6

Quello che faccio in questa situazione, che è molto comune, è quella di dividere i dati in due tabelle:

• dati richiesti
• dati opzionali

Per esempio, io' Attualmente sto scrivendo un sito Web della comunità e una delle tabelle sarà ovviamente una tabella utente. Sto registrando una grande quantità di informazioni sugli utenti e così ho diviso i dati raccolgo in due tabelle:

• Utenti
• UserDetails

I utenti tabella contiene le informazioni di base che ho avrà bisogno di tutto il tempo come Username, Name e Session Information.

Il UserDetails contiene informazioni aggiuntive che non ho bisogno di frequente come pagina profilo, indirizzo email, password, indirizzo sito web, data di nascita e così via.

Questo è noto come vertical partitioning.

Answer 7

La probabilità più alta di NULL nella colonna, più vicino alla fine del record, la colonna deve essere nella tabella (nella colonna lat nella tabella).
I NULLS alla fine della riga non hanno allocazione di spazio, sono determinati da NULL BITMAP collegato a ciascun record (sono 2 byte, ogni bit di cui parla di (non) NULL-ness di uno dei valori della colonna in atto).

Ora i valori NULL non vengono letti dalla colonna, vengono letti da bitmap NULL. Quando viene rilevato NULL la lettura valore reale viene saltato

La funzione sparse deve essere usato con precauzioni come invoca sovraccarico nel tempo e nello spazio per valori non nulli Per prestazioni, si può impegnarsi filtered indexing on non-null part of a column