Link alla notizia: https://www.hwupgrade.it/news/web/se-il-tuo-cognome-e-null-rischi-che-il-mondo-digitale-ti-si-rivolti-contro_136113.html

Il WSJ ha raccontato le disavventure di alcune persone che di cognome fanno "Null". In informatica, infatti, "null" è usato per indicare un valore nullo o inesistente, e questo in alcuni casi può comportare grandi problemi.

Click sul link per visualizzare la notizia.

Mi fa venire in mente una striscia di XKCD anche se il contesto e' differente:

https://imgs.xkcd.com/comics/exploits_of_a_mom.png

negli anni si è letto di tanta gente che ha cambiato il cognome per motivi abbastanza ovvi, ma pensare che uno possa avere un problema per un nome , tutto sommato , semplice , ma letteralmente in "contrasto" con le tecnologie moderne non lo avrei mai immaginato, anche perché non pensavo esistesse "Null" come cognome.

Personalmente ho sempre reputato l'esistenza di valori di tipo nullable in SQL una ca@ata pazzesca... Si, ok, se non memorizzi il dato risparmi qualche byte, ma tutti i casini che ci saremmo evitati se semplicemente non fosse stato possibile mettere un valore a NULL valeva decisamente il sacrificio... In nessuno dei database progettati da me e' possibile mettere dei valori a NULL, e quando scrivo codice evito di mettere qualsiasivoglia tipo di puntatore a nullptr, per non parlare di puntatori non inizializzati (anche se in quel caso i warning vengono in mio soccorso)... Da anni ci sono metodi migliori per capire se un puntatore contiene un valore valido, come evitare il puntatore a prescindere ed utilizzare qualcosa come std::optional o std::expect... Non per fare lo sborone, ma non credo sia un caso se i processi che faccio in C++ per i clienti sono gli unici, fra tanti fornitori, che possono stare su anche per centinaia di giorni senza crash e senza memory leak...

@jepessen onestamente non ho capito, a me sembra esattamente il contrario di quel che stai dicendo ma magari ho interpretato male. Io lavoro su SQL Oracle, i valori nullabili esistono e una stringa 'NULL' non può essere equiparata al valore NULL, sono due cose diverse e meno male altrimenti si ricasca nei casi indicati.
Per quanto sia assurda la stringa che usi hai sempre il rischio che ci sia un valore che corrisponda e non sia un NULL, a meno che non usi la stringa "X Æ A-12" ... a no! nemmeno quella
:sofico:

Il problema sta proprio lì, nella mancata gestione dei valori nullabili. Se il campo è mandatory sei costretto a "simulare" i NULL con delle stringhe strane, poi ti ritrovi in questi casi. Perché i NULL propriamente detti esistono non puoi far finta di no. Magari non il cognome (e sarebbe da verificare, magari da qualche parte nel mondo si usano solo i nomi) ma ci sono infinità di altri casi in cui il campo può essere vuoto.

@jepessen onestamente non ho capito, a me sembra esattamente il contrario di quel che stai dicendo ma magari ho interpretato male. Io lavoro su SQL Oracle, i valori nullabili esistono e una stringa 'NULL' non può essere equiparata al valore NULL, sono due cose diverse e meno male altrimenti si ricasca nei casi indicati.
Per quanto sia assurda la stringa che usi hai sempre il rischio che ci sia un valore che corrisponda e non sia un NULL, a meno che non usi la stringa "X Æ A-12" ... a no! nemmeno quella
:sofico:

Il problema sta proprio lì, nella mancata gestione dei valori nullabili. Se il campo è mandatory sei costretto a "simulare" i NULL con delle stringhe strane, poi ti ritrovi in questi casi. Perché i NULL propriamente detti esistono non puoi far finta di no. Magari non il cognome (e sarebbe da verificare, magari da qualche parte nel mondo si usano solo i nomi) ma ci sono infinità di altri casi in cui il campo può essere vuoto.

Si ma quando hai un valore null in SQL molti programmatori mettono 'null' nel loro codice, per non avere un puntatore vuoto o perche' proprio non possono usare i puntatori... Tutti i problemi scritti nell'articolo derivano dal fatto che un valore nullo nel database nel codice viene rappresentata con una stringa 'null', che e' uguale al cognome, o alla targa.

Ad esempio tutte le multe arrivate a chi ha la targa 'null' sono quelle per cui per qualsiasi motivo, errore della polizia o altro, non sono associate ad una targa specifica, quindi la targa non viene memorizzata nel database. Se fai una query devi comunque avere una targa da memorizzare e ottieni 'null', a questo punto vedi quale macchina ha quella targa, ed ottieni il casino.

Campi che possono essere vuoti per me sono un code smell, se proprio non puoi farne a meno puoi utilizzare un valore di default che comunque NON e' ammesso fra quelli validi, ad esempio per una targa potrebbe essere qualcosa come "@NULL@" o "NOT DEFINED" dato che i caratteri speciali non sono ammessi nelle targhe, e che hanno una lunghezza definita, oppure -1 se e' un valore numerico positivo. Ma avere una stringa che ti rappresenta un valore nullo, con un contenuto che puo' effettivamente essere valido e' un errore di design a mio avviso.

Si ma quando hai un valore null in SQL molti programmatori mettono 'null' nel loro codice, per non avere un puntatore vuoto o perche' proprio non possono usare i puntatori... Tutti i problemi scritti nell'articolo derivano dal fatto che un valore nullo nel database nel codice viene rappresentata con una stringa 'null', che e' uguale al cognome, o alla targa.

Ad esempio tutte le multe arrivate a chi ha la targa 'null' sono quelle per cui per qualsiasi motivo, errore della polizia o altro, non sono associate ad una targa specifica, quindi la targa non viene memorizzata nel database. Se fai una query devi comunque avere una targa da memorizzare e ottieni 'null', a questo punto vedi quale macchina ha quella targa, ed ottieni il casino.

Campi che possono essere vuoti per me sono un code smell, se proprio non puoi farne a meno puoi utilizzare un valore di default che comunque NON e' ammesso fra quelli validi, ad esempio per una targa potrebbe essere qualcosa come "@NULL@" o "NOT DEFINED" dato che i caratteri speciali non sono ammessi nelle targhe, e che hanno una lunghezza definita, oppure -1 se e' un valore numerico positivo. Ma avere una stringa che ti rappresenta un valore nullo, con un contenuto che puo' effettivamente essere valido e' un errore di design a mio avviso.

I programmatori che usano la stringa 'NULL' per NULL sono incompetenti.

In quanto al definire un valore non ammesso tra quelli validi, il problema è proprio che i valori che hai scritto sono possibili, per cui la tua soluzione fa c@g@re. Incidentalmente, il valore NULL e la stringa 'NULL' sono valori diversi.

Se vuoi che una colonna non contenga campi NULL, è sufficiente dichiararlo NOT NULL nella creazione della tabella.

Insomma, non hai mai visto un database in vita tua e non sai i problemi sottostanti. Ti consiglio di trovare un testo di base su SQL e studiare la normalizzazione di Codd. Prima di parlare a vanvera di certi argomenti non sarebbe male studiarli.

Mah... ora ci sono linguaggi dove si può specificare se una variabile può essere null o non-nullable. Poi ci si scontra con i valori di default... se NULL fosse stata una brutta cosa nei nuovi linguaggi il NULL non esisterebbe mai (in Rust per esempio non c'è il null ma un None ma la variabile a quel punto non è di tipo T ma Option<T>).

Bisogna solo gestirli ed è time-consuming.

Poi non parliamo di oracle, che ok che "Null" non è NULL, ma "" (stringa vuota) per oracle è NULL.

A giudicare come si sta evolvendo la discussione si conferma che:
"Se il tuo cognome è 'Null' rischi che il mondo digitale ti si rivolti contro "
a pensare che io mi son fermato ai tempi agli inizi di C++ e qualche piccola programmazione ancora prima sul C64 :asd:

I programmatori che usano la stringa 'NULL' per NULL sono incompetenti.

In quanto al definire un valore non ammesso tra quelli validi, il problema è proprio che i valori che hai scritto sono possibili, per cui la tua soluzione fa c@g@re. Incidentalmente, il valore NULL e la stringa 'NULL' sono valori diversi.

Se vuoi che una colonna non contenga campi NULL, è sufficiente dichiararlo NOT NULL nella creazione della tabella.

Insomma, non hai mai visto un database in vita tua e non sai i problemi sottostanti. Ti consiglio di trovare un testo di base su SQL e studiare la normalizzazione di Codd. Prima di parlare a vanvera di certi argomenti non sarebbe male studiarli.

senza essere così aggressivo :) , quoto il concetto.
se chi scrive il codice (che sia C++, python, C#, SQL o altro) non sa gestire un NULL è un problema di competenza, non del "dato in se".

Ma che problemi vi creano i null ?
Ok per alcuni dati il valore di default anzichè il null ci può stare.
Io lo uso sempre per i numeri. Tra Avere null o zero preferisco sicuramente trovarmi zero.
Ma per le date come fate senza null?
mettete 01.01.0001 ? o 01.01.1900 ?

Ci sono tanti casi in cui un data deve semplicemente essere null perchè il valore non è applicabile e da più fastidio che altro.
Idem per le stringhe.
Ed anche in molti contesti di calcolo scientifico è preferibile avere null anzichè zero nel DB.

Si ma quando hai un valore null in SQL molti programmatori capre che neanche dovrebbero toccare un pc mettono 'null' nel loro codice, per non avere un puntatore vuoto o perche' proprio non possono usare i puntatori...

Fixed.

L'unico vero problema è quella $robaFetidaMarroneSecca chiamata COBOL che non ha il concetto di NULL/NIL/OPTION come i linguaggi che non risalgono all'allunaggio :muro:

Con COBOL tutto deve essere valorizzato, quindi nel tempo è stato anche scritto codice con placeholder che avessero il significato di null (invece di usare flag che indicassero un campo come null).

Usare DB relazionali o non nel 2025 senza usare nullable fields è da pensionamento anticipato o calcione nel di dietro.

A giudicare come si sta evolvendo la discussione si conferma che:
"Se il tuo cognome è 'Null' rischi che il mondo digitale ti si rivolti contro "
a pensare che io mi son fermato ai tempi agli inizi di C++ e qualche piccola programmazione ancora prima sul C64 :asd:

Solo se hai a che fare con la PA (e qualche banca) che magari usa ancora COBOL che gira su un AS400 in cantina, ma nessuno che programma in linguaggi degli ultimi 20 anni si scandalizzerebbe.

Il problema è che internet si basa su linguaggi mediocri tipo Javascript dove si possono fare le peggiori porcate senza ritegno.

Solo un sistema progettato male può scambiare la stringa "null" con il *valore* NULL. :rolleyes:

Solo se hai a che fare con la PA (e qualche banca) che magari usa ancora COBOL che gira su un AS400 in cantina, ma nessuno che programma in linguaggi degli ultimi 20 anni si scandalizzerebbe.

Piccolo appunto, ero probabilmente sui 17-18 anni, lontani dai tempi attuali di internet, parlavo con un signore e non mi ricordo in che occasione, solo che per qualche motivo uscì fuori il discorso PC, che mi piaceva e blablabla, e questo se ne uscì dicendo se conoscevo Cobol e che lui ci aveva lavorato per anni.
Dopp quella volta, quando parlavo con i pochi che al tempo come me piaceva stare su PC, gli citavo il Cobol e questi mi guardavano stralunati.

Meno male che qualcuno qui ha tirato fuori il Cobol (che non conosco).
Perché stavo facendo oggettivamente molta fatica a capire come un sistema/software potesse trovarsi in difficoltá con una stringa "Null" come se ci fosse una qualche chance di confonderla con il valore NULL.
Mai avuto questo problema, né in Java, né C++, né C#, ne Python, né Javascript, né SQL, né PHP etc etc

--Il problema è che internet si basa su linguaggi mediocri tipo Javascript dove si possono fare le peggiori porcate senza ritegno.

Concordo. Javascript dovrebbe essere un linguaggio da ricerca/sperimentazione, non uno dei pilastri della moderna civiltá tecnologica.

Piccolo appunto, ero probabilmente sui 17-18 anni, lontani dai tempi attuali di internet, parlavo con un signore e non mi ricordo in che occasione, solo che per qualche motivo uscì fuori il discorso PC, che mi piaceva e blablabla, e questo se ne uscì dicendo se conoscevo Cobol e che lui ci aveva lavorato per anni.
Dopp quella volta, quando parlavo con i pochi che al tempo come me piaceva stare su PC, gli citavo il Cobol e questi mi guardavano stralunati.

Puoi anche aggiungere al repertorio il PL1 , Fortran, basic ed il clipper.
Tutta roba morta su cui gira probabilmente metà delle transazioni bancarie mondiali.

Puoi anche aggiungere al repertorio il PL1 , Fortran, basic ed il clipper.
Tutta roba morta su cui gira probabilmente metà delle transazioni bancarie mondiali.

Ricordo che io di programmazione ne so poco, conosco molti nomi ma non li ho mai usati (ad esempio, a parte , ovviamente Basic, ma anche per averlo usato, conosco Fortran di nome e gli altri 2 appena sentiti).

Ho tirato fuori sto discorso perché quando me ne parlò quel signore, sembrava di parlare di qualcosa di giurassico, senza sapere che era effettivamente un qualcosa di molto vecchio per già fine anni 90.

Poi beh, è un'inezia, ma COBOL è difficile da dimenticare come nome.

Ma che problemi vi creano i null ?
Ok per alcuni dati il valore di default anzichè il null ci può stare.
Io lo uso sempre per i numeri. Tra Avere null o zero preferisco sicuramente trovarmi zero.
Ma per le date come fate senza null?
mettete 01.01.0001 ? o 01.01.1900 ?

Ci sono tanti casi in cui un data deve semplicemente essere null perchè il valore non è applicabile e da più fastidio che altro.
Idem per le stringhe.
Ed anche in molti contesti di calcolo scientifico è preferibile avere null anzichè zero nel DB.

Stai attento a usare 0 invece di NULL.
Se per esempio devi fare una media dei valori presenti, lo 0 fa media, mentre NULL viene escluso.

Per cui, AVG(2,4,0) --> 2
mentre AVG(2,4,NULL) --> 3

Ecco questo è un buon esempio del perchè usare null ha senso in diversi casi.

Nelle medie che ho fatto fino ad ora lo zero doveva essere considerato quindi era ok.
Ma come dici tu l'esempio è calzante.

Per non parlare del caso in cui stai memorizzando un valore che può essere sia positivo che negativo. prendi le temperature, c'è lo zero, il -1 e c'è il null quando quel giorno la misura non è arrivata.

Oppure stai misurando delle fluttuazioni in delta di qualche valore, anche lì zero vuol dire che non c'è variazione rispetto al giorno prima, null che non ha (ancora una volta) la misura, ecc.

insomma, il null è un non-valore e ha il suo perché, bisogna farsene una ragione e gestirlo come si deve. E' time consuming? anche fare del codice senza bug è time consuming, devi fare quella roba brutta che corrisponde al nome di test (e prepararti i dati per poterlo fare, ecc. ecc.)