SQL Server - Colonne NULL

domenica 12 ottobre 2008 - 11.52

Elenco Threads

Stanze Forum

Aggiungi ai Preferiti

Cerca nel forum

fotw Profilo | Newbie

24 messaggi | Data Invio: dom 12 ott 2008 - 11:52

Faccio riferimento ad una affermazione che ha fatto Lorenzo (Benaglia)

- Sbagli a fare in modo che TUTTE le colonne possano accettare il (non)valore NULL.
Devi adottare la strada opposta: definisco tutte le colonne come NOT NULL,
e imposto a NULL SOLO quelle due o tre colonne che coerentemente con la logica
applicativa possono rimanere non valorizzate.

Vi chiedo se esiste un motivo tecnico di SQL Server o e' semplicemente una filosofia di lavoro di Lorenzo?

Io sono del parere opposto, tutte le colonne devono accettare NULL (tranne le PK)
e gestire nei programmi (o nelle viste - che io utilizo moltissimo), il valore di default.
Questo approccio, secondo me, porta dei vantaggi nel momento in cui, durante
la normale manutenzione delle applicazioni, si devono aggiungere colonne alle
tabelle. Non si rende obbligatorio ripassare i records già presenti e il tutto
funziona correttamente.

Vi ringrazio della disponibilità

Ciao a tutti

lbenaglia Profilo | Guru

5.625 messaggi | Data Invio: dom 12 ott 2008 - 15:23

>Vi chiedo se esiste un motivo tecnico di SQL Server o e' semplicemente
>una filosofia di lavoro di Lorenzo?

Ciao Gilberto,

Il discorso si applica a tutti i DBMS, non è una peculiarità di SQL Server.

>Io sono del parere opposto, tutte le colonne devono accettare
>NULL (tranne le PK)
>e gestire nei programmi (o nelle viste - che io utilizo moltissimo),
>il valore di default.
Che succede se si interviene direttamente sulla base dati senza passare dal tuo strato applicativo oppure se quest'ultimo risulta essere bacato o peggio ancora compromesso?
Tutte queste regole cablate nel codice non verranno prese in considerazione, con il rischio di inserire gravi errori logici nei dati.
Un db deve contenere TUTTE le regole necessarie a mantenerlo in uno stato logico consistente (e la nullability delle colonne è una di queste).
Se una informazione è necessaria in un determinato contesto, che senso ha offrire la possibilità di non inserirla, gestendo l'anomalia nel software applicativo?
L'applicazione prima di scrivere in una base dati deve eseguire un processo di validazione degli stessi, ma il DBMS deve eseguire nuovamente tali verifiche in modo da garantire la correttezza logica e formale delle informazioni rese persistenti nel database.

>Questo approccio, secondo me, porta dei vantaggi nel momento
>in cui, durante
>la normale manutenzione delle applicazioni, si devono aggiungere
>colonne alle
>tabelle.
L'aggiunta di nuove colonne non fa parte della "normale manutenzione" ma denota una insufficiente analisi nella progettazione della base dati.

>Vi ringrazio della disponibilità
Prego.

Ciao!
--
Lorenzo Benaglia
Microsoft MVP - SQL Server
http://blogs.dotnethell.it/lorenzo/
http://italy.mvps.org

alx_81 Profilo | Guru

8.814 messaggi | Data Invio: dom 12 ott 2008 - 16:39

>- Sbagli a fare in modo che TUTTE le colonne possano accettare
>il (non)valore NULL.
>Devi adottare la strada opposta: definisco tutte le colonne come
>NOT NULL,
>e imposto a NULL SOLO quelle due o tre colonne che coerentemente
>con la logica
> applicativa possono rimanere non valorizzate.
>
>Vi chiedo se esiste un motivo tecnico di SQL Server o e' semplicemente
>una filosofia di lavoro di Lorenzo?
No, no.. non è una filosofia di lavoro di Lorenzo. E' proprio una linea guida consigliata anche dai massimi esperti di SQL Server (E Lorenzo è molto esperto credimi).
Io parto sempre cercando di far capire che NULL è un valore che significa "SCONOSCIUTO" da utilizzare solo se necessario. Ovvero solo dove il campo ha LOGICAMENTE bisogno di essere SCONOSCIUTO. Ad esempio, in una gerarchia fatta con due campi IDUtente e IDPadre, ha senso che l'utente in testa all'albero abbia un campo IDPadre NULL. Poichè il padre di una radice di un albero è SCONOSCIUTO. Oppure, sai la data di inizio di un evento, ma la fine non la sai fino a che non succede qualcosa che lo chiuda. Un ipotetico campo DataFine può valere NULL, poichè la chiusura dell'evento, almeno per un periodo, è ancora SCONOSCIUTA.
Ma se prendi una tabella contenente i dipendenti di un'azienda, nella quale sono salvati i valori minimi di paga base per ogni dipendente e sei certo di conoscere tutti i valori, un campo del genere non ha senso che sia NULLABLE, è LOGICAMENTE SCORRETTO. E in più, se qualcuno che mette le mani al db e che non conosce la situazione reale prova a non inserire nulla in quel campo, il DB non si DIFENDE e lascia inserire valori che poi possono dare seri problemi alle applicazioni che vi si basano.
Insomma, il primo è un discorso logico.
Il secondo è invece un discorso di coding, quindi più tecnico. Immagina se sui campi NULLABLE tu dichiari delle relazioni con delle JOIN da SQL. E' molto più complesso e pesante gestire dei dati con OUTER JOIN e i campi NULLABLE devono essere gestiti nella SELECT, con funzioni proprietarie come la ISNULL o la COALESCE.
Inoltre, certe condizioni basate su NULL, potrebbero indurre SQL Server a non usare correttamente gli indici definiti.
E ancora.. attenzione al comportamento dei campi NULL. Certe JOIN o condizioni in generale, per la nostra logica, sono corrette, perchè interpretiamo il valore SCONOSCIUTO un po' come NON VERO. Ma non è così. Per un RDBMS il NULL è gestibile, ma come socnosciuto. Quindi alcune condizioni o relazioni potrebbero dare risultati non attesi rispetto a quanto noi ci ponevamo all'inizio.

>Io sono del parere opposto, tutte le colonne devono accettare
>NULL (tranne le PK) e gestire nei programmi (o nelle viste - che io utilizo moltissimo),
>il valore di default. Questo approccio, secondo me, porta dei vantaggi nel momento
>in cui, durante la normale manutenzione delle applicazioni, si devono aggiungere
>colonne alle tabelle. Non si rende obbligatorio ripassare i records già presenti
>e il tutto funziona correttamente.
Non sono d'accordo con te per le cose indicate sopra. E comunque, in fase di aggiunta di una colonna, c'è sempre una parte di sviluppo che crea uno script per la pubblicazione in test e produzione (DEVE ESSERCI) che consenta di non perdere informazioni o che non blocchi l'applicazione.

>Vi ringrazio della disponibilità
Ciao!

di nulla!

--

Alessandro Alpi | SQL Server MVP

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

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 !