A quale livello preferisci gestire i valori Null nella tua applicazione?
La mia preferenza personale al momento è il DB. Quando costruisco una vista, mi assicuro di restituire un valore al posto di un valore NULL. Quindi, se l'app front-end dovesse connettersi all'applicazione, non avrebbe mai dovuto gestire i null.
Nelle mie app VB6, ho fatto un uso liberale della funzione IsNull per gestire i null.
Condividi le tue esperienze.
Questo è uno dei problemi con null. Ogni volta che lo sviluppatore del database li inserisce nel database, lo sviluppatore dell'applicazione deve rimuoverli. Molto spesso la politica migliore è quella di evitare o minimizzare l'uso di valori nulli nelle tabelle di base per iniziare. Se vengono utilizzati i valori nulli, è una buona idea registrare da qualche parte esattamente cosa si intende per null e perché viene utilizzato. È quindi possibile inserire la logica in una vista o una stored procedure per eliminare o sostituire i valori null in modo appropriato.
Anche se non c'è assolutamente una risposta unica a questa domanda, penso che sia meglio lasciare i dati trasparenti. Se stai gestendo i valori nulli nel database e non li hai mai restituiti all'applicazione, qual è il punto in cui archiviare valori null? Sembra analogo restituire sempre il valore di una colonna intera + 1.
Questo non vuol dire che null debba essere usato liberamente nell'intera applicazione. Se la tua selezione sta semplicemente facendo IsNull(FieldName, '') , perché non rendere semplicemente la colonna non annullabile e memorizzare invece la stringa vuota? Potrai rendere i tuoi dati più fedeli alla tua logica di business e potrebbe rendere la tua scelta più veloce (certamente se stai filtrando su quella colonna).
Una volta ho visto una lista (non riesco a trovare il riferimento, ahimé!) di 13 diverse semantiche possibili per NULL, variando i significati come Valore sconosciuto, Valori in conflitto, Non applicabile, Vuoto, Predefinito.
Se si tenta di elaborare tutti questi significati nel database, si finisce con una grande quantità di logica aziendale laggiù. Viceversa, per alcuni significati, può essere utile isolare il livello della logica di business dagli interni del database, ad es. fornendo un valore predefinito. Dipende davvero dal problema che stai affrontando e da cosa questo particolare tipo di valore NULL intende significare.
Ero solito fare quello che descrivi, utilizzare ISNULL (Column1, '') o simile nella vista o nella stored procedure in modo che non abbia mai (o raramente) dovuto trattare un null nell'applicazione. Ma ho scoperto che a volte un NULL è solo il modo più appropriato per rappresentare uno stato "sconosciuto", anche all'interno dell'applicazione. Quindi, a meno che non abbia una ragione specifica per il tipo di logica "ISNULL", ora passo quei NULL alla pipe. In effetti, ho cercato di ottenere tutta la mia logica di database nel modo più puro possibile (semplici SELECT, UPDATE, INSERT o DELETE) con la minore logica possibile. Quindi, ho superato la mia paura dei NULL. Il tuo chilometraggio può variare!
Il problema con NULL è che non è molto descrittivo. Ad esempio, i dati mancanti ma applicabili o mancanti e inapplicabili? Potresti stare meglio, dal punto di vista dell'applicazione, quando il DB (tramite un processo memorizzato, ad esempio) ti dice perché i dati non sono disponibili, in modo che l'applicazione possa intraprendere l'azione appropriata.
Lo trovo davvero dipendente dalla logica aziendale. Passare NULL a un campo dell'interfaccia utente che verrà semplicemente visualizzato come vuoto di solito è OK. A volte i NULL devono essere gestiti nel database a livello di vincolo per i campi in cui NULL non può essere consentito. A volte potrebbe essere gestito nel mezzo, se il database è accessibile da più app - alcune che sono OK con NULL e altre che non lo sono.
Se stai chiedendo questo su come gestire null all'interno di un'applicazione come un valore inaccettabile; la risposta è ogni luogo in cui null potrebbe rappresentare un problema.
La programmazione difensiva è spesso trascurata e gli sviluppatori sostengono che il livello N si occuperà della convalida dei dati e ignorerà la convalida dei dati. A meno che non sia in atto un contratto forzato o l'isolamento del codice consenta flessibilità nell'approccio, devi sempre proteggerti da valori nulli e / o dati errati.
Sappiamo tutti cosa succede quando si assume ...
I NULL hanno il loro posto. Supponi di avere la colonna [FoodExpiresOn] DATETIME NULL nella tabella dbo. [FoodProducts]. Un valore NULL (un twinkie non va mai male) è altrettanto significativo di un valore non nullo.