[Database] Valori null e prestazioni

[Kahm]

salve a tutti

ho creato una routine per l'inserimento nel database di alcuni valori
ho fatto diverse if per i valori per vedere se erano valorizzati, e in caso contrario li impostavo a "Null",ovviamente concatenando il tutto per creare la stringa SQL

esempio:

if variabile ="" then
      variabile ="NUll"    'imposto a null il valore
else
     variabile="'" & replace(variabile,"'","''")   & "'"    'metto apici e replace
end if

il mio capo guardando si è quasi spaventando
dichiarando che tutte quelle if avrebbero influito sulle prestazioni, e che sarebbe meglio non gestire i null,anzi mettere stringa vuota nel db

il mio capo ha 20 anni di esperienza, e non mi va di contraddirlo, ma secondo voi è corretto quello che ha detto?
in effetti dovrei gestire una quindicina di variabile e controllare il valore e impostarle a null se sono vuote,e il null implica piu velocita di esecuzione nelle query nel database

cosa mi dite? ho un forte dubbio
grazie

[riccardone]

Se usi i parametri oltre a far contento il tuo capo poi non devi fare nessun replace. Aggiungo che il valore null non e' mai una bella cosa e andrebbe evitato impostando nel db la colonna con un valore di default ('' es. nel caso di stringa) e in modo da non accettare valori null.

[Kahm]

il mio capo
non usa i parameters
in genere concatena il tutto in una stringa sql

cosa faccio?
graise

[pietro09]

1) il CAPO non si contraddice mai
2) i campi null sono utili e non vedo il motivo per non utilizzarli. Leggo: 'Virtualmente, tutti i database supportano il concetto di valore null nelle colonne. Questo valore speciale viene utilizzato spesso come sinonimo di "valore incognito" o "valore non assegnato"'
Sono tanto importanti, che il framework 2.0 ha introdotto i tipi nullable, ossia tipi value a cui può essere assegnato il valore null.

Detto questo, bisogna assolutamente usare i parametri.
Io uso da sempre, una vecchia funzione asp, riadattata:

	Public Function StringNullToDBNull(ByVal s$) As Object
		If (s = "") Then
			Return DBNull.Value
		Else
			Return s
		End If
	End Function

che non fa altro che convertire una stringa nulla, per esempio presa da un textbox vuoto, in DBNull.value


Aggiungo che ha sempre funzionato. Ciao

[riccardone]

Originariamente inviato da pietro09
2) i campi null sono utili e non vedo il motivo per non utilizzarli. Leggo: 'Virtualmente, tutti i database supportano il concetto di valore null nelle colonne. Questo valore speciale viene utilizzato spesso come sinonimo di "valore incognito" o "valore non assegnato"'
Sono tanto importanti, che il framework 2.0 ha introdotto i tipi nullable, ossia tipi value a cui può essere assegnato il valore null.

Utili?? E per cosa? L'unica cosa per cui sono utili i valori null consiste nell'inchiodare le applicazioni poco attente con dei bei castfromdbnull ecc. ecc.
Purtroppo i valori nulli provenienti dal db sono una realta' con cui siamo costretti a fare i conti ma se posso costruire da 0 la struttura di un db non ci penso due volte, quando cio e' possibile, a togliere i valori nulli e impostare dei valori di default per le colonne. In questa maniera si riducono le possibilita' di errore per l'applicazione che poi scrivo io oppure per le eventuali altre applicazioni scritte da altri (che magari non prestano le stesse attenzioni ai valori nulli). Questa e' la mia esperienza sul campo. Dopo di che, conosco anche programmatori bravissimi che vanno professando la possibilita' di utilizzare i database solo come semplici contenitori di dati senza affidarsi al db per gestire integrita' dei dati, relazioni ecc. ma gestendo il tutto nel cosidetto business layer. Questo per dire che in questo ambito si puo' dire tutto e il contrario i tutto.

[riccardone]

Originariamente inviato da Kahm
il mio capo
non usa i parameters
in genere concatena il tutto in una stringa sql

ma non hai detto che ha 20 anni di esperienza?
Come fate a non capire quanto sono utili e facili da usare i parametri che vi evitano tra l'altro sqlinjection, problemi con il formato dei dati (che puo' variare da server a server) ecc.?

[pietro09]

Originariamente inviato da riccardone
ma non hai detto che ha 20 anni di esperienza?
Come fate a non capire quanto sono utili e facili da usare i parametri che vi evitano tra l'altro sqlinjection, problemi con il formato dei dati (che puo' variare da server a server) ecc.?

carissimo Riccardone, almeno sui parametri, spero che siamo daccordo . A che servono 20 anni di esperienza se non si usano i parametri?

Comunque, non faccio altro che leggere quesiti sui campi data, in asp e in aspx, sui campi null, in asp e in aspx, con i relativi consigli di non utilizzare gli uni e gli altri. Ma, se li usano Access, è facile pensare che siano sbagliati. Diverso è se gli usano Oracle ed altri.
Allora, dato che io e altri usiamo i campi data ed i campi null senza avere mai avuto problemi, non è che altri non sappiano usarli? :master: Se questi campi fossero inutili o dannosi, perchè i progettisti di Oracle non gli hanno eliminati?
Le applicazioni, poi, si inchiodano se hanno errori. Chiunque sa o dovrebbe sapere, che i campi letti da database si debbono prima verificare che non siano null. Esattamente come non si può valutare la lunghezza di una stringa se questa non è istanziata

per Kahm

se il tuo capo è fatto così, tu prova a preparare due versioni della stessa routine:
la prima usa i parametri, la seconda la concatenazione di stringa sql.
Per la stringa sql, io, per prima cosa ricopierei quello che fa Access. Poi userei una cosa simile:

sql = String.Format("X {0} X {1} X {2} X", funzione0(), funzione1(), funzione2() )


per esempio, funzione1 può restituire una stringa:
se il campo di provenienza è vuoto -> Null
se non è vuoto restituisce il campo sostituendo gli apici con i doppi apici

per esempio, funzione1 può restituire una data
se il campo di provenienza è vuoto -> Null
se non è vuoto restituisce il campo nel formato #m/g/a#

per esempio, funzione1 può restituire un numero
se il campo di provenienza è vuoto -> Null
se non è vuoto restituisce il campo nel formato numero americano, es 1234.567


dopo di che, si fanno vedere le due routine al BOSS e si lascia decidere a LUI

ciao

[riccardone]

Originariamente inviato da pietro09
carissimo Riccardone, almeno sui parametri, spero che siamo daccordo . A che servono 20 anni di esperienza se non si usano i parametri?

Chiunque quando fa questo lavoro si sforzi di scrivere buon codice non puo' non usare i parametri quando interagisce con il db. Non usarli vuol dire scrivere codice orrendo e esposto a errori.

...Diverso è se gli usano Oracle ed altri. Allora, dato che io e altri usiamo i campi data ed i campi null senza avere mai avuto problemi, non è che altri non sappiano usarli? :master: Se questi campi fossero inutili o dannosi, perchè i progettisti di Oracle non gli hanno eliminati? Le applicazioni, poi, si inchiodano se hanno errori....

Allora se siamo in vena di filosofia perche' ogni database ha il suo dialetto diverso dagli altri visto che esiste lo standard sql? Perche' il mondo rdbms e' rimasto piatto e invece il mondo della programmazione a oggetti e' un insieme di informazioni in ordine gerarchico?
Ci muoviamo in mezzo a una marea di cose che sarebbero potute essere meglio e quindi in mezzo a questa marea sta a noi fare le scelte che ci mettono il piu' possibile al riparo di errori e ci facilitano il lavoro. I campi null (esistono in tutti i db) purtroppo non ci danno nessun aiuto se non dei bei errori. Io anche quando disegno da 0 il db metto in atto comunque le contromisure per gestire i valori null. Su quello non ci piove. Xo un db ben disegnato da questo punto di vista ti crea meno scocciature e poi se arriva un pisquano che fa la paginetta in asp o in chissa cosaltro senza avere a disposizione un framework che ti aiuta o l'accortezza di stare attento anche a lui risultera' piu' facile usare il db.

[ZofM]

Riccardone ha ragione (come sempre del resto), utilizzare valori NULL nei database non è la strada migliore per arrivare ad alti livelli di compattezza su un database relazionale.

Giusto, al giorno d'oggi la tendenza è quella di utilizzare i db come semplici archivio di dati ma se vario un record direttamente da uno di questi db senza passare per l'applicazione web/windows legata ad esso.. che succede?
"Un gran casein" come diciamo qui da noi (ipotizzate l'aggiornamento di un record che necessita l'aggiornamento in cascata di altre informazioni).

Prima di partire a sviluppare la nostra applicazione è bene sempre un analisi approfondita del problema, poi preparare e strutturare il database per renderlo il + normalizzato possibile (i criteri sono tanti..).

[cassano]

io uso spesso i nullable e devo dire che con i parametri possono essere una buona soluzione.