Tipi di dati varchar nullable e non null - che è più veloce per le query?

Question

Generalmente preferiamo che tutte le nostre colonne varchar/nvarcharnon annullabili con una stringa vuota ('') come valore predefinito. Qualcuno del team ha suggerito che annullabile è meglio perché:

Una query come questa:

Select * From MyTable Where MyColumn IS NOT NULL 

è più veloce di questo:

Select * From MyTable Where MyColumn == '' 

Chiunque ha alcuna esperienza per convalidare se questo è vero?

Answer 1

Su alcune piattaforme (e anche su versioni), questo dipenderà dal modo in cui i NULL vengono indicizzati.

La mia regola di base del pollice per NULL è:

1. Non permettere NULL fino giustificato

2. Non permettere NULL meno che i dati possono davvero essere sconosciuto

Un buon esempio di questo è la modellazione delle linee di indirizzo. Se si dispone di un AddressLine1 e AddressLine2, cosa significa per il primo di avere dati e il secondo di essere NULL? Mi sembra che tu conosca o meno l'indirizzo e che i NULL parziali in un insieme di dati richiedano solo problemi quando qualcuno li concatena e ottiene NULL (comportamento ANSI). È possibile risolvere questo problema con l'abilitazione dei valori NULL e l'aggiunta di un vincolo di controllo: tutte le informazioni sull'indirizzo sono NULL o nessuna.

Cosa simile con iniziale/nome medio. Alcune persone non ne hanno uno. È diverso da ciò che è sconosciuto e ti interessa?

Inoltre, data di morte: cosa significa NULL? Non morto? Data di morte sconosciuta? Molte volte una singola colonna non è sufficiente per codificare la conoscenza in un dominio.

Quindi, per me, sia per consentire valori null dipenderebbero molto dalle semantica dei primi dati - prestazioni sta per essere secondo, perché dopo aver male interpretato i dati (potenzialmente da molte persone diverse) è di solito un molto più costoso problema delle prestazioni.

Potrebbe sembrare una piccola cosa (in SQL Server l'implementazione è una maschera di bit memorizzata con la riga), ma solo consentire NULL dopo la giustificazione mi sembra che funzioni meglio. Cattura le cose nelle prime fasi dello sviluppo, ti costringe ad affrontare le ipotesi e capire il tuo dominio del problema.

Answer 2

Se si desidera sapere che non vi è alcun valore, utilizzare NULL.

Per quanto riguarda la velocità, IS NULL dovrebbe essere più veloce, perché non utilizza il confronto tra stringhe.

Answer 3

Dite a quel tizio della vostra squadra di ottenere la sua prematuramente ottimizin 'testa fuori dal suo culo! (Ma in un modo carino).

Gli sviluppatori di questo tipo possono essere veleno per il team, pieno di miti di ottimizzazione di basso livello, che possono essere veri o veri in un determinato momento per determinati modelli di fornitori o query, o forse solo per teoria, ma mai vera nella pratica.Agire su questi miti è una perdita di tempo dispendiosa e può distruggere un design altrimenti buono.

Probabilmente intende bene e vuole contribuire con la sua conoscenza alla squadra. Sfortunatamente, ha torto. Non è sbagliato nel senso che un benchmark dimostrerà la sua affermazione corretta o errata. Ha torto nel senso che non è così che si progetta un database. La questione se rendere un campo NULL-capable è una domanda sul dominio dei dati allo scopo di definire il tipo del campo. Si dovrebbe rispondere in termini di cosa significa che il campo non ha valore.

Answer 4

In breve, NULL = SCONOSCIUTO! .. Il che significa (utilizzando la data dell'esempio di morte) che l'entità potrebbe essere 1) viva, 2) morta ma la data di morte non è nota, o 3) sconosciuta se l'entità è vivo o morto. Per le colonne numeriche, le imposto sempre su 0 (ZERO) perché da qualche parte lungo la linea potresti dover eseguire calcoli di aggregazione e NULL + 123 = NULL. Per gli alfanumerici, io uso NULL dal suo meno costoso rendimento-saggio e più facile da dire '... dove è IS NULL' che dicendo '... dove a = ""'. Usare '... dove a = "" [spazio]' non è una buona idea perché [spazio] non è un NULL! Per le date, se devi lasciare una colonna di date NULL, potresti voler aggiungere una colonna di indicatori di stato che, nell'esempio precedente, A = Alive, D = Dead, Q = Dead, data di morte non nota, N = Alive o Morto è sconosciuto.

Answer 5

Se è necessario NULL, utilizzare NULL. Idem stringa vuota.

quanto riguarda le prestazioni, "dipende"

Se avete varchar, si memorizza un valore effettivo nella riga per la lunghezza. Se hai char, allora memorizzi la lunghezza effettiva. NULL non verrà memorizzato in fila a seconda del motore (bitmap NULL per SQL Server, ad esempio).

Ciò significa che IS NULL è più veloce, query per query, ma potrebbe aggiungere la complessità COALESCE/NULLIF/ISNULL.

Quindi, il tuo collega è parzialmente corretto ma potrebbe non apprezzarlo completamente.

ciecamente utilizzando stringa vuota è l'uso di un valore sentinella piuttosto che lavorare attraverso l'emissione NULL semantica

FWIW e personalmente:

• vorrei tendono utilizzare NULL, ma non sempre . Mi piace evitare date come 31 dic 9999 che è il punto in cui NULL evita la guida.

• Dalla risposta di Cade Roux ... Trovo anche che le discussioni su "La data della morte annullabile" sia inutile. Per un campo, in termini pratici, o c'è un valore o non c'è.

• I valori sentinella sono peggiori dei valori NULL. Numeri magici chiunque?