Implementazione dato - meglio NULL o testo vuoto?

sabato 12 febbraio 2011 - 20.47

Elenco Threads

Stanze Forum

Aggiungi ai Preferiti

Cerca nel forum

Elenco Tags SQL Server 2008 R2 | SQL Server 2008 | SQL Server 2005

andrestu Profilo | Expert

772 messaggi | Data Invio: sab 12 feb 2011 - 20:47

Pongo la domanda in relazione alle prestazioni di un server Sql e non ai relativi prò e contro nell'implementare un campo NULL oppure no. Cioè vorrei sapere in linea di massima qualè la scelta migliore in termini di prestazioni nell'effettuare elaborazioni, faccio questa domanda perchè avevo letto da qualche parte che il motore Sql fatica maggiormente ad interagire in una tabella con campi NULL che viceversa. cosa mi suggerite???

Andrea Restucci - Web Programmer
www.andrearestucci.name
Download and try my FREE custom controls !!!

speedx Profilo | Junior Member

111 messaggi | Data Invio: dom 13 feb 2011 - 15:19

Ciao,
Meglio NULL.... non ricordo di avere mai letto del problema che citi tu, ma da purista dico meglio NULL, se un valore non esiste, non esiste.
I default vanno messi quando in mezzo ci sono delle elaborazioni, tipo che sò un lavoro sulla province allora nel campo Codice provincia metti un valore 'XX' che identifica tutti i dati non appartenenti a nessuna provincia esistente...
//// Marcello C.

alx_81 Profilo | Guru

8.814 messaggi | Data Invio: mar 15 feb 2011 - 13:22

scusate se mi intrometto..
sull'argomento NULL ci sarebbe da investire più di un post.. Non è una cosa banale. Nè in termini di prestazioni (i/o soprattutto) nè in termini di sviluppo ed infine, nemmeno dal punto di vista dell'analisi del modello.
provo a spiegare quanto penso in poche righe, dividendo l'argomento come ho citato sopra:

- modellazione
in questo caso, è molto importante capire quando effettivamente serve un null. Come dice speedx Null significa Sconosciuto ed è quindi opportuno usare null se non si sa a priori il valore di una colonna. Ad esempio la data di fine di un particolare evento di cui non si sa la precisa durata. Oppure un valore che ancora non è pervenuto per cui c'è da gestire questo stato "unknown".

- sviluppo
questo è un passo fondamentale soprattutto per la manutenibilità del codice. NULL, non essendo un vero e proprio valore, può portare a gestione di eccezioni scomodissime. Ad esempio, una comparazione (che per definizione è impossibile) obbliga, se non diversamente impostato, ad usare l'operatore IS, a controllare eventuali variabili/campi prima di gestirle, a fare attenzione nelle funzioni di aggregazione e nelle espressioni matematiche e di concatenazione stringhe (ricordiamo che di default un null sbianca tutta una stringa che lo contiene). Ma il problema principale sta nella gestione del valore null particolare, senza la quale nascono voragini nel codice, potenzialmente dannose tanto quanto "invisibili" a volte.

- prestazioni
NULL occupa spazio eccome. Ad esempio, nei campi a lunghezza fissa come i char, NULL tiene come il char. Inoltre, se in una tabella andiamo a mettere l'opzione allow nulls nelle colonne, sql predispone se non erro un paio di bytes per la gestione dello stesso. Quindi è meglio, per quanto possibile anche logicamente, impostare il flag not null nelle colonne delle tabelle che andiamo a creare. Inoltre, IS NULL usato nelle query, non è particolarmente indicato per una buona prestazione dell'indice che utilizza quel campo.

>I default vanno messi quando in mezzo ci sono delle elaborazioni,
>tipo che sò un lavoro sulla province allora nel campo Codice
>provincia metti un valore 'XX' che identifica tutti i dati non
>appartenenti a nessuna provincia esistente...
Su questo non sono molto d'accordo. Sì, il default è un valore di inizializzazione se il campo può averlo, ma l'idea dei valori dummy non l'ho mai condivisa molto, allora in questo caso preferisco NULL, anche perchè mi pare bruttino ad esempio definire una foreign key sul campo "provincia" (ammesso che il modello sia normalizzato su quella tabella) per un valore dummy. Inoltre, sempre pensando allo sviluppo, il rischio è quello di popolare il codice di gestioni cablate, non trovi?

ciao a tutti e scusate l'intromissione!

--
Alessandro Alpi | SQL Server MVP
MCP|MCITP|MCTS|MCT

http://www.alessandroalpi.net
http://blogs.dotnethell.it/suxstellino
http://mvp.support.microsoft.com/profile/Alessandro.Alpi

andrestu Profilo | Expert

772 messaggi | Data Invio: sab 5 mar 2011 - 10:54

Ciao Ale,
grazie per l'ampia spiegazione data sull'argomento e a parte le varie implicazioni sulla modellazione e gestione di un dato NULL (che in riferimento ad un piccolo sito web può anche non essere un grosso problema) a me interessava sapere più che altro in termini di prestazioni il motore Sql se poteva essere appesantito dalla gestione di colonne NULL, appesantito intendo in termini di elaborazione CPU.
Il punto è che quando il dato inserito potrebbe essere opzionale (cioè per esempio l'utente potrebbe scegliere o no di inserire la propria città di nascita) a quel punto nel DB o si usa un valore NULL o si usa un valore predefinitto non penso ci possano essere altre alternative. E considerate le due opzioni a questo punto se non aggravo molto sulle prestazione SQL forse preferisco usare il NULL, lo vedo come "più pulito", tanto se usassi per esempio un valore predefinito in ogni caso dovrei fare lo stesso un controllo da codice sul dato restituito in modo da capire se è quello predefinito o meno e quindi a sto punto tanto vale farlo per capire se è NULL o meno. Mi sembra acnhe più pulito il codice risultante e forse anche più leggibile...

Andrea Restucci - Web Programmer
www.andrearestucci.name
Download and try my FREE custom controls !!!

alx_81 Profilo | Guru

8.814 messaggi | Data Invio: sab 5 mar 2011 - 22:30

>Ciao Ale,
ciao

>grazie per l'ampia spiegazione data sull'argomento e a parte
>le varie implicazioni sulla modellazione e gestione di un dato
>NULL (che in riferimento ad un piccolo sito web può anche non
>essere un grosso problema) a me interessava sapere più che altro
>in termini di prestazioni il motore Sql se poteva essere appesantito
>dalla gestione di colonne NULL, appesantito intendo in termini
>di elaborazione CPU.
certo, impatta sulle prestazioni, se non hai tantissimi dati e la macchina su cui gira è ben dimensionata, potresti anche non accorgertene. Però ricorda sempre l'accesso multiuser, che aumenta le chiamate e quindi anche le interrogazioni di conseguenza.

>Il punto è che quando il dato inserito potrebbe essere opzionale
>(cioè per esempio l'utente potrebbe scegliere o no di inserire
>la propria città di nascita) a quel punto nel DB o si usa un
>valore NULL o si usa un valore predefinitto non penso ci possano
>essere altre alternative. E considerate le due opzioni a questo
>punto se non aggravo molto sulle prestazione SQL forse preferisco
>usare il NULL, lo vedo come "più pulito", tanto se usassi per
>esempio un valore predefinito in ogni caso dovrei fare lo stesso
>un controllo da codice sul dato restituito in modo da capire
>se è quello predefinito o meno e quindi a sto punto tanto vale
>farlo per capire se è NULL o meno.
se il dato è opzionale, NULL è corretto, il valore è SCONOSCIUTO e, come detto, NULL significa SCONOSIUTO

>Mi sembra acnhe più pulito il codice risultante e forse anche più leggibile...
nel caso dei dati opzionali il controllo va fatto, e quindi cambierebbe poco, quello su cui sindaco di solito è l'ammettere i NULL per i campi di cui si sa il valore (o non si sa), l'usare SCONOSCIUTO quando il valore o c'è o non c'è. Gli opzionali, puoi scegliere tu, e trovo corretto l'utilizzo del NULL se non si conosce un valore di campo.
Ci sono casi invece in cui il problema è che potresti scegliere una logica per cui ti aspetti valorizzato sempre il campo (su cui hai impostato in analisi ed in design "ammetti NULL") e il tuo codice necessita manutenzioni successive per risolvere l'eventuale arrivo di valori NULL (con il conseguente probabile errore). Diciamo che bisogna sempre fare attenzione alla gestione del NULL (pensa le condizioni di join, le where preesistenti, ecc.)

--
Alessandro Alpi | SQL Server MVP
MCP|MCITP|MCTS|MCT

http://www.alessandroalpi.net
http://blogs.dotnethell.it/suxstellino
http://mvp.support.microsoft.com/profile/Alessandro.Alpi

Torna su

Stanze Forum

Elenco Threads

Partecipa anche tu! Registrati!

Hai bisogno di aiuto ?
Perchè non ti registri subito?

Dopo esserti registrato potrai chiedere
aiuto sul nostro Forum oppure aiutare gli altri

Consulta le Stanze disponibili.

Registrati ora !