MySQL onderscheid 0 en NULL
Maar nu geeft hij ook de rijen waar gekeurd NULL is niet terug. Hoe krijg ik MySQL zo ver dat hij NULL en 0 niet als gelijk behandeld in dit geval? Ik begin m'n verbinding al met:
Wat overigens wel werkt, maar.. toch.. dit is lelijk:
Je laatste statement is dus de enige juiste, ook al vind je het lelijk.
Helemaal correct. Overigens hoef je een nullable kolom geen default waarde NULL mee te geven. Ik persoonlijk geef er de voorkeur aan dan wel een een specifieke waarde op te geven.
Ger van Steenderen op 09/06/2012 13:02:40:
Helemaal correct. Overigens hoef je een nullable kolom geen default waarde NULL mee te geven.
Huh? NULL is het ontbreken van een bekende waarde, er valt niks te zeggen over deze onbekende waarde. Dus hoe wil je dan de default waarde NULL opgeven wanneer het geen waarde is?
Wanneer je niks invult en geen default waarde hebt gedefinieerd voor een kolom, blijft deze automatisch NULL.
Code (php)
1
2
3
4
5
6
7
8
2
3
4
5
6
7
8
CREATE TABLE test(id INT, getal INT);
INSERT INTO test(id) VALUES(1);
INSERT INTO test(id,getal) VALUES(2, NULL); -- NULL mag niet tussen quotes staan!
SELECT id, getal FROM test WHERE id = 1;
SELECT id, getal FROM test WHERE getal IS NULL;
INSERT INTO test(id) VALUES(1);
INSERT INTO test(id,getal) VALUES(2, NULL); -- NULL mag niet tussen quotes staan!
SELECT id, getal FROM test WHERE id = 1;
SELECT id, getal FROM test WHERE getal IS NULL;
MySQL doet rare dingen met NULL's, in elk geval met DATE en DATETIME. Vertrouw daar niet op, maar dat kan met MySQL toch al niet...
Ps. Volgens mij bedoel je het wel goed, leg je het alleen wat ongelukkig uit.
Toevoeging op 09/06/2012 13:41:50:
Jelmer rrrr op 09/06/2012 10:09:48:
Wat je (in theorie) zou kunnen doen, is COALESCE() gebruiken:
COALESCE() vervangt een NULL (in dit geval) door een 1. En dan heb je weer een match.
Máár.... hierdoor kan de database géén gebruik meer maken van een index op de kolom "gekeurd". Wanneer er weinig records in deze tabel staan, is dat geen probleem, in andere gevallen kan dit een performance probleem worden. Dus mocht je al een index op deze kolom hebben staan, is dit waarschijnlijk geen bruikbare oplossing.
Ps. Een kolom "status" van het type INT, SMALLINT of TINYINT die verwijst naar een andere tabel (met foreign key) met alle mogelijke statussen, lijkt mij fraaier. Een boolean (tinyint in jouw geval) duidt vaak op een sub-optimaal datamodel. In dat geval heb je het probleem van COALESCE en een index ook niet meer.