[SQL] Implementeren van redenen voor NULL

[CurlyMo]

Ik ben bezig met een database ontwerp en zit een beetje te stoeien met het verklaren van een NULL. Een zoektocht op dit forum leverde me opvallenderwijs niks op dat specifiek over deze kwestie gaat, terwijl ik me niet kan voorstellen dat men hier niet vaker tegenaan loopt.

In het stuk How To Handle Missing Information Without Using Null wordt de suggestie gedaan om voor elke reden een aparte 1 kolom tabel te maken. Als in één van die aparte kolom tabellen het persoon ID staat, dan is deze reden geldig. Dit lijkt mij echter onwenselijk omdat je dan allerlei 1 kolom tabellen hebt voor elke kolom in de database die een NULL waarde kan hebben. Een ander probleem wat ik met dit ontwerp heb is dat een tabel op zichzelf een representatie van een waarde wordt i.p.v. de gegevens die in de tabel staan. Ik hoop dat ik het begrijpelijk uitleg.

Zelf zat ik te denken om een tabel redenen_null te maken die via verschillende koppeltabellen is verbonden met de tabellen met mogelijke NULL kolommen. Op deze manier heb je één tabel met mogelijke verklaringen voor NULL die via een koppeltabel te koppelen is aan andere tabellen.

In mijn situatie zouden mogelijke reden voor NULL kunnen zijn: onbekend, ongeautoriseerd, geen waarde.

Dus concreet. Ik heb een kolom met mogelijke waarden of NULL. In het geval van NULL moet ik op een of andere manier kunnen achterhalen waarom de kolom NULL is.

[ Voor 5% gewijzigd door CurlyMo op 21-10-2015 22:21 ]

[HMS]

NULL staat binnen (relationele) databases voor het onbekend zijn van een waarde. Dit verklaart de situatie dat NULL != NULL, want twee onbekende waardes kan je niet met elkaar vergelijken. Ik zou er voor kiezen om de situatie 'geen waarde' niet als NULL te modeleren, maar expliciet te behandelen. NULL kan je dan reserveren voor 'onbekend'.

Uit het voorbeeld in je link zou dus 'Unemployed' ook gewoon een 'Job' zijn, en 'Job unknown' zou dan NULL zijn. Hetzelfde gaat op voor 'Salary unknown' (NULL) en 'Unsalaried' (0).

Ik snap niet helemaal wat je precies met de reden 'ongeautoriseerd' wil.

[CurlyMo]

HMS schreef op woensdag 21 oktober 2015 @ 16:52:
Ik zou er voor kiezen om de situatie 'geen waarde' niet als NULL te modeleren, maar expliciet te behandelen. NULL kan je dan reserveren voor 'onbekend'.

Dat is precies mijn vraag. Wat zijn de best-practices om dit te implementeren?

HMS schreef op woensdag 21 oktober 2015 @ 16:52:
Ik snap niet helemaal wat je precies met de reden 'ongeautoriseerd' wil.

Dat betekent dat de informatie wel ergens anders bekend is, wij het op dit moment (nog) niet mogen weten, maar in de toekomst misschien wel.

Neem bijvoorbeeld een patiënt die geen toestemming heeft gegeven voor een EPD en waar bij de cliënt bij psychologische gezondheid staat: niet-geautoriseerd. Dat betekent niet dat degene geen psychisch probleem heeft en ook niet dat het nergens bekend is. Het betekent precies wat het zegt. De betreffende arts heeft niet de permissie om het überhaupt te mogen weten, maar waar dat in de toekomst misschien verandert.

[Gomez12]

CurlyMo schreef op woensdag 21 oktober 2015 @ 16:58:
[...]
Dat betekent dat de informatie wel ergens anders bekend is, wij het op dit moment (nog) niet mogen weten, maar in de toekomst misschien wel.

Neem bijvoorbeeld een patiënt die geen toestemming heeft gegeven voor een EPD en waar bij de cliënt bij psychologische gezondheid staat: niet-geautoriseerd. Dat betekent niet dat degene geen psychisch probleem heeft en ook niet dat het nergens bekend is. Het betekent precies wat het zegt. De betreffende arts heeft niet de permissie om het überhaupt te mogen weten, maar waar dat in de toekomst misschien verandert.

Het voorbeeld wat jij geeft is dus eigenlijk dat er wel bekend is wat de status is, namelijk dat die ergens anders staat.

Maar sowieso als je een uitlegtabel voor nullables hebt dan heb je het al niet meer over 1 uitleg, dan heb je het over verschillende statussen imho. Null =onbekend en niets anders bij mij.

Nullable vind ik echt simpelweg onbekend omdat er nog totaal geen data bekend is.
Dus in jouw situatie van een patient dan kan bij de 1e invoer de waarde onbekend/null zijn (omdat de secretaresse het nog niet weet) maar na het 1e bezoek moet het gewoon een status zijn want dan weet je het wel.

Of een ander voorbeeld wat ik in de praktijk meegemaakt heb, een bedrijf deed orderkosten per gewicht (en het gewicht had ruime marges). Het veld orderkosten in de verkooporder werd door business rules op 0 ingevuld onder de 8 kg, op bedrag x boven de 12 kg en tussen de 8 en 12 kg was het veld null (bij default) echter de factuur tabel kende geen nullable veld orderkosten, want op het moment dat er een factuur gemaakt moest worden moest er duidelijk zijn of het daadwerkelijke gewicht onder of boven de 10kg zat (dus 0 of x bedrag orderkosten).
De telefonische verkoper hoefde het bedrag niet te weten want dat was onmogelijk vanaf zijn plek en de ruime marges die er waren qua gewicht, maar in het magazijn moest het wel gewogen worden want er moest gewoon een bedrag gefactureerd worden.

Net zoiets heb ik altijd met een veldje geslacht, dat kan initieel nullable zijn bij een 1e invoer (bijv vanaf een visitekaartje), maar als de klant voor je heeft gestaan of als de klant het zelf ingevuld heeft dan kan het niet nullable meer zijn (alhoewel je wel allerlei geslachtsmogelijkheden en transgender mogelijkheden hebt, maar het kan niet meer null zijn)

Null is echt 100% onbekend en niet voorlopig onbekend (dat is een status), tijdelijk onbekend (dat is wederom een status), ongeauthoriseerd is meer een default status bij 1e invoer, geen waarde is gewoon een lege string.
Op het moment dat je een reden hebt voor een null heb je het imho of over een bit-field, of over een enum van meerdere redenen.

[BoringDay]

Praktisch nut kan zijn een checklist
Is een vraag ja/nee of is een vraag niet beantwoord.
Wanneer je een vraag initialiseert met nee of ja, dan weet je niet of de vraag wel gesteld is.

[ Voor 3% gewijzigd door BoringDay op 21-10-2015 18:54 ]

[MrMonkE]

Wat er in je link staat lijkt me academische gezwets. Gewoon null gebruiken, doet de hele wereld behalve een gek van de universiteit van Warwick University. Volgens mij wordt je van het datamodel en de code die je daarvoor moet schrijven/generen en het gebruik daarvan knettergek en kost het 10x zoveel tijd.
Wanneer is iets null? Als het onbekend is.

[ Voor 12% gewijzigd door MrMonkE op 21-10-2015 19:02 . Reden: typo ]

[incaz]

Volgens mij zijn er globaal twee haalbare opties:
1. of je gebruikt statusvelden (op zich ook handig is voor labels en rapportage en eventuele meertaligheid, omdat je dan gewoon de labeltabel kunt switchen, en soms maakt het de logica makkelijker, vooral als je moet selecteren op 'onbekend'),
2. of je handelt de nulls af in je applicatie zelf, bij voorkeur zo hoog mogelijk door calculated fields / templates / custom elements die netjes een null-value omzetten in een begrijpelijke uitleg.

Volgens mij zijn dat de twee haalbare opties. Het klooien met aparte tabellen voegt m.i. niets toe.

Als je per eigenschap moet weten waarom iets onbekend is, zou ik het in een status gooien. Als het volgt uit een hogergelegen eigenschap (bv als bepaalde details niet van toepassing zijn), dan zou ik het gewoon null laten omdat je dan toch die hogere eigenschappen nodig hebt om de weergave logisch te maken.

En verder open staan voor momenten waarop je denkt 'nu ben ik dit wel erg vaak aan het doen, laat ik het omzetten naar een andere methode.' Dat klinkt eng, maar als je een klein beetje netjes werkt valt het wel mee. Zelfs in het onwaarschijnlijk exotische framework waar ik ooit mee gewerkt heb was dat best te doen.
De huidige frameworks en talen hebben daar nog veel meer mogelijkheden voor.

[CurlyMo]

MrMonkE schreef op woensdag 21 oktober 2015 @ 19:02:
Wanneer is iets null? Als het onbekend is.

Dat het gangbaar is om NULL te gebruiken wanneer een waarde onbekend is begrijp ik en dat is in 99% van de gevallen voldoende. De eis is simpelweg dat we moeten weten waarom een waarde onbekend is. De vraag is hoe ik dat het beste kan doen.

Gomez12 schreef op woensdag 21 oktober 2015 @ 18:51:
[Null is echt 100% onbekend en niet voorlopig onbekend (dat is een status), tijdelijk onbekend (dat is wederom een status), ongeauthoriseerd is meer een default status bij 1e invoer, geen waarde is gewoon een lege string.
Op het moment dat je een reden hebt voor een null heb je het imho of over een bit-field, of over een enum van meerdere redenen.

Hier wil ik best in meegaan. Hoe doe ik dit dan het best?

[Gomez12]

BoringDay schreef op woensdag 21 oktober 2015 @ 18:53:
Praktisch nut kan zijn een checklist
Is een vraag ja/nee of is een vraag niet beantwoord.
Wanneer je een vraag initialiseert met nee of ja, dan weet je niet of de vraag wel gesteld is.

Praktisch nut waarvoor bedoel je precies?

Ja/nee/niet beantwoord lijken mij perfecte statussen.
Null is enkel een ongestelde vraag (waardoor je er geen antwoord op weet)

CurlyMo schreef op woensdag 21 oktober 2015 @ 19:46:
[...]
Dat het gangbaar is om NULL te gebruiken wanneer een waarde onbekend is begrijp ik en dat is in 99% van de gevallen voldoende. De eis is simpelweg dat we moeten weten waarom een waarde onbekend is. De vraag is hoe ik dat het beste kan doen.

Als je moet weten waarom een situatie onbekend is dan is die per definitie niet meer onbekend.
Ik heb het idee dat je voornamelijk in de knoei lijkt te komen doordat je je definitie van onbekend niet eenduidig wilt stellen, onbekend is onbekend en het waarom is dus ook onbekend.
Als het waarom bekend is maar het antwoord niet dan heb je dus 2 velden (of 1 gecombineerd veld).

Als ik het voorbeeld van BoringDay neem, dan heb ik in wezen 4 waarden (ja/nee/niet beantwoord/niet gesteld) waarbij de laatste 2 hetzelfde antwoord opleveren (ik weet niet of het ja of nee is).
Dat kan ik opschrijven als een nullable boolean alleen dan heb ik een 2e bit-veld nodig om te vatten of de vraag wel of niet gesteld is, wat bij een ja/nee antwoord impliciet in het antwoord zit. Of ik heb 3 statussen en een nulwaarde voor het niet stellen.

Welke daadwerkelijke implementatie je pakt is aan jezelf en aan de situatie, wellicht is er wel een vraag : Heeft u 1 van mijn vragen beantwoord? Dan is het ja/nee impliciet te trekken uit de andere vragen en is het stellen van de vraag niet meer nodig om een antwoord op deze vraag te krijgen. Oftewel dan kan ik een antwoord invullen zonder de vraag te stellen, dan heb je dus een extra bit-veld nodig want dan is een ja/nee niet meer impliciet dat de vraag gesteld is.

Het is maar net wat je wilt weten en waarin je geïnteresseerd bent wat de beste aanpak is.

[CurlyMo]

Gomez12 schreef op woensdag 21 oktober 2015 @ 20:13:
Als je moet weten waarom een situatie onbekend is dan is die per definitie niet meer onbekend.
Ik heb het idee dat je voornamelijk in de knoei lijkt te komen doordat je je definitie van onbekend niet eenduidig wilt stellen, onbekend is onbekend en het waarom is dus ook onbekend.
Als het waarom bekend is maar het antwoord niet dan heb je dus 2 velden (of 1 gecombineerd veld).

Daarin verschil ik van mening. Ik weet dat iedereen een geboortedatum heeft net als ouders. Als ik niet weet wat die zijn, dan zijn de waarde voor mij onbekend. Dat staat los van de reden waarom het onbekend is.

Als ik het voorbeeld van BoringDay neem, dan heb ik in wezen 4 waarden (ja/nee/niet beantwoord/niet gesteld) waarbij de laatste 2 hetzelfde antwoord opleveren (ik weet niet of het ja of nee is).

Dat zou inderdaad kunnen in een integer veld. Je maakt dan bijvoorbeeld alles groter dan 0 als daadwerkelijke waarden en alles kleiner dan 0 als statussen. In het geval van een geboortedatum wordt het echter minder wenselijk. Soms wordt er dan maar gekozen voor een 01-01-1900 als onbekende geboortedatum, maar dat is echter gewoon een foute waarde invullen. Vandaar dat ik graag naar een goede status implementatie zoek voor de redenen van onbekende waarden.

[Gomez12]

CurlyMo schreef op woensdag 21 oktober 2015 @ 20:22:
[...]
Daarin verschil ik van mening. Ik weet dat iedereen een geboortedatum heeft net als ouders. Als ik niet weet wat die zijn, dan zijn de waarde voor mij onbekend. Dat staat los van de reden waarom het onbekend is.

Hier zeg je het exact goed.

Je wilt in wezen 2 dingen weten :
- De geboortedatum
- De reden dat je de geboortedatum niet weet

Dat zijn 2 losstaande dingen zoals jij het beschrijft, dus 2 velden in je database. Probeer die niet in 1 veld te proppen als je ze alletwee wilt weten.

In wezen in deze situatie zou ik zeggen :
- Geboortedatum : NULL
- Reden : Mevrouw werd agressief toen ik ernaar ging vragen
Gewoon 2 losse velden. En dan kan je het 2e veld als enum implementeren of als string voor mijn part.

CurlyMo schreef op woensdag 21 oktober 2015 @ 20:22:
[...]
Dat zou inderdaad kunnen in een integer veld. Je maakt dan bijvoorbeeld alles groter dan 0 als daadwerkelijke waarden en alles kleiner dan 0 als statussen. In het geval van een geboortedatum wordt het echter minder wenselijk. Soms wordt er dan maar gekozen voor een 01-01-1900 als onbekende geboortedatum, maar dat is echter gewoon een foute waarde invullen. Vandaar dat ik graag naar een goede status implementatie zoek voor de redenen van onbekende waarden.

Heb je een rdbms waar je per kolom moet betalen oid? Als je 2 onafhankelijke gegevens wilt weten moet je gewoon in 2 kolommen 2 gegevens opslaan, niet gaan klooien met magische waarden die iets moeten kunnen betekenen, of extreem exotische tabel-structuren.

Maar is de reden voor het ontbreken van een geboortedatum echt een concreet voorbeeld of een fantasie-voorbeeld? Want dat is een geval waar geen enkele status je verder gaat helpen, je gaat altijd statussen missen, daar is de enige goede implementatie een memo-veld waarin iemand zijn halve levensverhaal kwijt kan over waarom hij zijn geboortedatum niet weet

[CurlyMo]

Gomez12 schreef op woensdag 21 oktober 2015 @ 20:35:
Hier zeg je het exact goed.

Je wilt in wezen 2 dingen weten :
- De geboortedatum
- De reden dat je de geboortedatum niet weet

Ok we zijn het er over eens dat ik in wezen twee dingen wil weten. Dat probeerde ik allicht wat onhandig duidelijk te krijgen.

Dat zijn 2 losstaande dingen zoals jij het beschrijft, dus 2 velden in je database. Probeer die niet in 1 veld te proppen als je ze alletwee wilt weten.

In wezen in deze situatie zou ik zeggen :
- Geboortedatum : NULL
- Reden : Mevrouw werd agressief toen ik ernaar ging vragen
Gewoon 2 losse velden. En dan kan je het 2e veld als enum implementeren of als string voor mijn part.

[...]

Heb je een rdbms waar je per kolom moet betalen oid? Als je 2 onafhankelijke gegevens wilt weten moet je gewoon in 2 kolommen 2 gegevens opslaan, niet gaan klooien met magische waarden die iets moeten kunnen betekenen, of extreem exotische tabel-structuren.

De vraag is alleen hoe dat het meest efficiënt te implementeren is.
1. De schrijver van het artikel zegt een aparte 1 kolom tabel per reden.
2. Jij zegt per NULL veld een tweede reden van NULL veld.
3. Mijn idee was een reden tabel met koppeltabel.

Maar is de reden voor het ontbreken van een geboortedatum echt een concreet voorbeeld of een fantasie-voorbeeld? Want dat is een geval waar geen enkele status je verder gaat helpen, je gaat altijd statussen missen, daar is de enige goede implementatie een memo-veld waarin iemand zijn halve levensverhaal kwijt kan over waarom hij zijn geboortedatum niet weet

Het gaat niet om de situaties dat iemand zijn eigen geboortedatum niet weet, maar waarin ik als informatieverwerker het niet weet. Voor dat niet weten zijn uiteenlopende redenen die ik wil kunnen registeren.

Vergelijkbare voorbeelden heb ik eerder al gegeven. Geboortedatum en psychische gezondheid ware daar twee van.

[Cartman!]

Gomez12 schreef op woensdag 21 oktober 2015 @ 20:35:
[...]
Heb je een rdbms waar je per kolom moet betalen oid?

Ik moest lachen... ik voel een nieuw verdienmodel aankomen

Ik zou voor ja/nee/niet beantwoord/niet gesteld ook een int pakken als je onderscheid wil maken tussen niet beantwoord en niet gesteld. Als je die kunt samenvoegen lijkt een nullable boolean ook prima.

[Gomez12]

CurlyMo schreef op woensdag 21 oktober 2015 @ 21:38:
[...]
De vraag is alleen hoe dat het meest efficiënt te implementeren is.
1. De schrijver van het artikel zegt een aparte 1 kolom tabel per reden.
2. Jij zegt per NULL veld een tweede reden van NULL veld.
3. Mijn idee was een reden tabel met koppeltabel.

Optie 3 is in wezen hetzelfde als mijn optie 2, alleen dan genormaliseerd. Ik zou niet moeilijk doen met een koppeltabel maar gewoon de reden in een enum zetten. Koppeltabel is imho overbodig en onduidelijk, enum is een soort mini-koppeltabel maar dan binnen 1 veld zodat je geen bijna doublures hebt etc, alles wat erin staat heeft direct betrekking op de tabel waar hij instaat.
Terwijl je met een koppeltabel vermoed ik allerlei bijna doublures gaat krijgen die maar net iets anders zijn wat je allemaal weer moet afvangen etc.

En optie 1 tja, bedenk je eens in wat het maximale aantal onbekende velden is bij een compleet nieuwe patient kan krijgen en dat zou je dan als tabellen aanmaken voor 1 entiteit, dan heb je nog een entiteit adres en zo heb je nog wel tig entiteiten die elke weer tig tabellen vereisen met 1 kolom.
Als je houdt van een verhouding van 10:1 qua nutteloze tabellen en nuttige tabellen dan is het een optie

[...]
Het gaat niet om de situaties dat iemand zijn eigen geboortedatum niet weet, maar waarin ik als informatieverwerker het niet weet. Voor dat niet weten zijn uiteenlopende redenen die ik wil kunnen registeren.

Maar hoeveel redenen zijn dat dan nog? Dat lijken me nog maar een 5 of 10 en dat valt weer perfect te passen in een enum.

[Gomez12]

Cartman! schreef op woensdag 21 oktober 2015 @ 21:59:
[...]
Ik zou voor ja/nee/niet beantwoord/niet gesteld ook een int pakken als je onderscheid wil maken tussen niet beantwoord en niet gesteld. Als je die kunt samenvoegen lijkt een nullable boolean ook prima.

Waarom een int en niet een enum?

Weet jij over 2 jaar nog wat een waarde 3 ook alweer was als je in de dbase moet kijken of moet je dan opeens in documentatie gaan graven welk tabelletje daar ook alweer bijhoorde?

[FeronIT]

Ik vraag me af om de schrijver van dat artikel ooit echt met een DB gewerkt heeft

NULL kun je gewoon gebruiken als de waarde niet (bij jou) bekend is. Als je wil weten waarom een waarde leeg is, is dat gewoon een ander gegeven. Wil je dan misschien ook weten waarom een waarde wel bekend is?

[CurlyMo]

Ik weet het nog niet. Ik zie in zowel de koppeltabel als het aparte union veld voor en nadelen. Ik begrijp in ieder geval dat de mensen die tot nu toe reageren hier nooit eerder tegenaan zijn gelopen buiten een obscure schrijver van dat artikel

[Alain]

Ik heb niet het hele artikel en het topic doorgelezen, maar waarom een koppeltabel? Een koppeltabel gebruik je voor een n:m relatie.

Je wilt extra informatie toevoegen aan een veld dat NULL kan zijn. Dit is dus gewoon een extra veld.

[CurlyMo]

Omdat je de redenen van het NULL zijn daarmee onafhankelijk maakt van je NULL velden in je tabellen. Of dat de juiste implementatie is is waar dit topic voor bedoelt is.

[Gomez12]

CurlyMo schreef op woensdag 21 oktober 2015 @ 22:16:
Ik weet het nog niet. Ik zie in zowel de koppeltabel als het aparte union veld voor en nadelen. Ik begrijp in ieder geval dat de mensen die tot nu toe reageren hier nooit eerder tegenaan zijn gelopen buiten een obscure schrijver van dat artikel

Ehm, ik loop hier zowat wekelijks tegenaan. Alleen dan meer in de offerte-trajecten, daar is een offerte wel gegund, of niet gegund, of onbekend en bij dat onbekend is er dan een reden en die reden kan weer een vervolgactie hebben en die vervolgactie kan weer een workflow eraan gekoppeld hebben, die kan weer een bepaalde status hebben (wederom oa onbekend) die weer een reden kan nodig hebben die bijv weer een opvolgdatum nodig kan hebben etc. etc.

Alleen dat zijn hele opvolgtrajecten die aan een null-status hangen, met bijbehorende tabellen en business logica.

Wat jij lijkt te beschrijven is een simpel status veldje met 5 of 10 statussen en daar heb je helemaal geen circus voor nodig, daar hebben ze enum voor uitgevonden.

Laat ik het eens anders vragen. Je was het ermee eens dat het 2 gegevens waren, als we nu even het null-gedeelte wegdenken. We gaan ons puur focussen op de reden die jij vastgelegd wilt hebben.
Dan kan je die reden op zichzelf net zo goed zien als de reden waarom de patient je kliniek binnen komt.
Oftewel bij een nieuw bezoek van een patient zal je ook op moeten geven wat de reden van het bezoek was, hoe los je dat op? Ga je daar ook moeilijk zitten doen met tabellen met 1-koloms dingen etc, of met union-dingen.

Je vraag is in essentie gewoon : Hoe sla ik een reden / status op in een db, dat die hier toevallig gekoppeld is aan een null-veld veranderd niets aan je essentiele vraag

[cannibal]

CurlyMo schreef op woensdag 21 oktober 2015 @ 22:16:
Ik weet het nog niet. Ik zie in zowel de koppeltabel als het aparte union veld voor en nadelen. Ik begrijp in ieder geval dat de mensen die tot nu toe reageren hier nooit eerder tegenaan zijn gelopen buiten een obscure schrijver van dat artikel

Misschien zegt dat dan ook genoeg

Maar ik zou zelf idd gaan voor het extra veld en of je dat dan als (tiny)int doet, of link naar een stamtabel is dan vooral naar keuze.

Zou niet kiezen voor een extra tabel waar je veel naar moet schrijven, zodra je dan flink wat throughput krijgt in je database dan kan zo'n tabel al vlug een locking-issue krijgen zonder allerlei ingrepen. En dat zonder dat het nodig is.

[Gomez12]

CurlyMo schreef op woensdag 21 oktober 2015 @ 22:31:
Omdat je de redenen van het NULL zijn daarmee onafhankelijk maakt van je NULL velden in je tabellen. Of dat de juiste implementatie is is waar dit topic voor bedoelt is.

Vergeet het null zijn, dat is irrelevant. Je lijkt te denken dat null iets speciaals is terwijl het dat helemaal niet is.
Vervang null door patient : Omdat je de redenen van het patient zijn daarmee onafhankelijk maakt van je patient velden in je tabellen.

Zie je daar wel een oplossing voor of ook niet?

cannibal schreef op woensdag 21 oktober 2015 @ 22:33:
[...]
Zou niet kiezen voor een extra tabel waar je veel naar moet schrijven, zodra je dan flink wat throughput krijgt in je database dan kan zo'n tabel al vlug een locking-issue krijgen zonder allerlei ingrepen.

Ehm, we hebben het toch wel over een serieuze SQL-implementatie en niet een SQL-voor dummy's implementatie? Veel schrijven zegt niets over locking-issues in een serieus SQL systeem, daar schrijf je gewoon met rowlocks en niet met tablelocks.

[CurlyMo]

Gomez12 schreef op woensdag 21 oktober 2015 @ 22:37:
[...]

Vergeet het null zijn, dat is irrelevant. Je lijkt te denken dat null iets speciaals is terwijl het dat helemaal niet is.

Je punt is gemaakt. En nee, ik ben niet aan het werk in Access of MySQL

[ Voor 61% gewijzigd door CurlyMo op 21-10-2015 22:45 ]

[Alain]

CurlyMo schreef op woensdag 21 oktober 2015 @ 22:31:
Omdat je de redenen van het NULL zijn daarmee onafhankelijk maakt van je NULL velden in je tabellen. Of dat de juiste implementatie is is waar dit topic voor bedoelt is.

Ik zit zelf ook wel eens met dit soort doordenkers, maar je denkt te ver door.

De reden dat iets NULL kan zijn (als je het al wilt weten) is afhankelijk van het veld dat NULL kan bevatten. Waarom onafhankelijk maken?

Een geboortedatum die NULL is heeft een x aantal redenen. Het niet weten van een salaris heeft een x aantal redenen. Deze redenen zijn gerelateerd aan het veld (misschien met enige overlap). Iedereen weet zijn salaris, maar niet iedereen weet zijn geboortedatum. Een reden "Ik weet het niet" is dus niet toepasbaar op beide velden.

[CurlyMo]

Knuffelbeer schreef op woensdag 21 oktober 2015 @ 22:44:
[...]


Ik zit zelf ook wel eens met dit soort doordenkers, maar je denkt te ver door.

Misschien het resultaat van al twee dagdelen met een alleen al het database schema bezig zijn. Dan zie je door alle bossen de bomen niet meer of was het nu andersom

[ Voor 3% gewijzigd door CurlyMo op 21-10-2015 22:52 ]

[MrMonkE]

Als je heel vies wil doen maak je het een text veld. Als je de waarde niet naar een datum kunt parsen dan is de datum onbekend en de string bevat in dat geval de reden. Al dan niet in de vorm van een naar enum te casten int of gewoon als text. Super ranzig, zou door geen enkele code review heen mogen komen.
Maar het kan wel. Maar doe dingen omdat het goed is, niet omdat het mogelijk is.

[incaz]

CurlyMo schreef op woensdag 21 oktober 2015 @ 22:16:
Ik weet het nog niet. Ik zie in zowel de koppeltabel als het aparte union veld voor en nadelen. Ik begrijp in ieder geval dat de mensen die tot nu toe reageren hier nooit eerder tegenaan zijn gelopen buiten een obscure schrijver van dat artikel

Maak het jezelf vooral niet te moeilijk. Dit soort dingen kom je wel tegen, maar de simpele oplossingen voldoen meestal voldoende. Een tabel per kolom, en unions, zijn draken om mee te werken, dus dat lijkt me al snel een no go.

De rest... da's een beetje een afweging waar de grens is naar waar het zinnig wordt. Zo kun je prima een algemeen veld hebben voor 'reden onbekend' als kolom naast een nullable boolean. De overhead van 1 kolom is vrij klein, zeker als het op z'n meest een smallint is in opslag.

Dat wordt uiteraard wel wat anders als je heel veel eigenschappen moet opslaan die alleen in bepaalde voorwaarden van belang zijn. Zou de 'reden onbekend' bv aanleiding zijn tot een hele serie van aantekeningen met tekstvelden, ingelogde gebruiker, datum, etc, dan wordt het al een stuk zinniger om dat in een eigen tabel te doen (met een fk op oorspronkelijke entry uiteraard)

Laat je daarin sturen door het gebruik, die grenzen zijn niet altijd langs hele scherpe lijnen verdeeld, er zit een omslagpunt waar het ene of het andere makkelijker wordt.

MrMonkE schreef op donderdag 22 oktober 2015 @ 11:15:
Maar het kan wel. Maar doe dingen omdat het goed is, niet omdat het mogelijk is.

Waarom zou je iets noemen alleen 'omdat het kan'? Wat heeft de TS daaraan? Vooral aangezien hij zoekt naar de beste manier om het te doen, en niet naar de obscuurste / meest dubieuze?

[MrMonkE]

incaz schreef op donderdag 22 oktober 2015 @ 11:42:
Waarom zou je iets noemen alleen 'omdat het kan'? Wat heeft de TS daaraan? Vooral aangezien hij zoekt naar de beste manier om het te doen, en niet naar de obscuurste / meest dubieuze?

Omdat dat het meest in lijn is met wat hij oorspronkelijk wilde.
Iets slechts.

[DJMaze]

CurlyMo schreef op woensdag 21 oktober 2015 @ 16:28:
Dus concreet. Ik heb een kolom met mogelijke waarden of NULL. In het geval van NULL moet ik op een of andere manier kunnen achterhalen waarom de kolom NULL is.

Stel je eens voor:

code:

CREATE TABLE gebruikers (
    gebruiker_achternaam VARCHAR(100)
);
INSERT INTO gebruikers VALUES (NULL);
INSERT INTO gebruikers VALUES ('');
INSERT INTO gebruikers VALUES ('Mijn achternaam');
INSERT INTO gebruikers VALUES ('0');
INSERT INTO gebruikers VALUES (0x00);

Welke SELECT queries gebruik je?
Hoe presenteer je de informatie in een applicatie?

[ Voor 3% gewijzigd door DJMaze op 22-10-2015 18:25 ]

[CurlyMo]

Precies daarom zijn die 0, 0x00, en '' niet toegestaan.

[ajakkes]

En hoe ga je bijhouden wat dan de reden van NULL is?

Gebruiker krijgt een formulier van een patiënt om in te vullen. Vakje psychische status weet hij het antwoord niet op dus slaat het over. Krijgt hij dan een verplicht vakje met: wat is de reden van NULL? En worden anders alle gegevens niet opgeslagen? Of sla je op gebruiker heeft het niet ingevuld?

[DJMaze]

CurlyMo schreef op donderdag 22 oktober 2015 @ 18:59:
Precies daarom zijn die 0, 0x00, en '' niet toegestaan.

Dus je beboelt zoiets als:

code:

CREATE TABLE gebruikers (
    gebruiker_achternaam VARCHAR(100),
    gebruiker_achternaam_error int not null default 1 COMMENT '1 = not validated, 2 = invalid character, 3=...'
);
INSERT INTO gebruikers VALUES (NULL);
INSERT INTO gebruikers VALUES ('');
INSERT INTO gebruikers VALUES ('Mijn achternaam', 0);
INSERT INTO gebruikers VALUES ('0');
INSERT INTO gebruikers VALUES (0x00);

[CurlyMo]

Dat is ook wat anderen hier voorstelde.

[Gomez12]

DJMaze schreef op vrijdag 23 oktober 2015 @ 13:44:
[...]

Dus je beboelt zoiets als:

code:

CREATE TABLE gebruikers (
    gebruiker_achternaam VARCHAR(100),
    gebruiker_achternaam_error int not null default 1 COMMENT '1 = not validated, 2 = invalid character, 3=...'
);
INSERT INTO gebruikers VALUES (NULL);
INSERT INTO gebruikers VALUES ('');
INSERT INTO gebruikers VALUES ('Mijn achternaam', 0);
INSERT INTO gebruikers VALUES ('0');
INSERT INTO gebruikers VALUES (0x00);

Het nadeel van je voorbeeld is dat dat weer een andere situatie is als de TS lijkt te willen vanwege je comments. Er kan best een geldige achternaam zijn die not validated is zolang die niet gevalideerd is tegen een externe bron.

Wat TS lijkt te zoeken is :

code:

INSERT INTO gebruikers VALUES (NULL,1);
INSERT INTO gebruikers VALUES (NULL,2);
INSERT INTO gebruikers VALUES ('Mijn achternaam', 0);
INSERT INTO gebruikers VALUES (NULL,3);
INSERT INTO gebruikers VALUES (NULL,4);

[DJMaze]

Gomez12 schreef op vrijdag 23 oktober 2015 @ 16:45:
[...]

Het nadeel van je voorbeeld is dat dat weer een andere situatie is als de TS lijkt te willen vanwege je comments. Er kan best een geldige achternaam zijn die not validated is zolang die niet gevalideerd is tegen een externe bron.

Wat TS lijkt te zoeken is :

code:

INSERT INTO gebruikers VALUES (NULL,1);
INSERT INTO gebruikers VALUES (NULL,2);
INSERT INTO gebruikers VALUES ('Mijn achternaam', 0);
INSERT INTO gebruikers VALUES (NULL,3);
INSERT INTO gebruikers VALUES (NULL,4);

In deze situatie kan je niet meer zien wat er mis is aan de waarde, de waarde is immers op NULL gezet.
Als je dus ergens toont "fout in e-mailadres" dan weet je dus verder niks meer.

[CurlyMo]

DJMaze schreef op woensdag 28 oktober 2015 @ 10:34:
In deze situatie kan je niet meer zien wat er mis is aan de waarde, de waarde is immers op NULL gezet.
Als je dus ergens toont "fout in e-mailadres" dan weet je dus verder niks meer.

In dat geval wordt het mail adres wel opgeslagen, maar met een melding dat het een ongeldig waarde is.

[incaz]

DJMaze schreef op woensdag 28 oktober 2015 @ 10:34:
In deze situatie kan je niet meer zien wat er mis is aan de waarde, de waarde is immers op NULL gezet.
Als je dus ergens toont "fout in e-mailadres" dan weet je dus verder niks meer.

Ik zou voor dergelijke zaken een importtabel gebruiken met de ruwe data, en vervolgens die gegevens omzetten naar de normale tabellen. Dan kun je altijd nazoeken wat er nou precies stond, maar het opslaan van allerlei ongeldige / onhandige karakters lijkt me een garantie op problemen in weergaves, api, afdrukken, verwerken in batchscripts... Bij de gewone tabellen zou ik dus vooral zorgen dat je in een naam-veld echt alleen maar geldige namen hebt en null, en de ruwe data en obscure null-characters daar lekker buiten houden.

En als de data rechtstreeks binnenkomt, dan uiteraard vooral al eerder afvangen.

[CurlyMo]

Mijn idee is een aanvullende log kolom te maken. Stel er komt een ongeldige geboortedatum binnen, dan wordt deze ofwel opgeslagen (mits dit in het format past van een datum) met een label ongeldig opgeslagen of niet opgeslagen met het label ongeldig niet opgeslagen. In beide gevallen komt er wel een regel in de log kolom te staan met de oorspronkelijke geboortedatum zodat terug te zoeken is wat er precies werd afgewezen voor dat record.

[incaz]

Dan zou ik er op z'n minst een log-tabel van maken, zodat je een historie kunt opbouwen van wat er gebeurt. Anders ben je bij een wijziging die info alsnog kwijt.

Overigens: iets dat ongeldig is moet je niet opslaan in het record dat je gebruikt. Dat geeft datacorruptie, dat moet je niet willen. Als je niet de juiste waarde weet, dan is de waarde van geboortedatum gewoon null. De ruwe data kun je dan elders houden, en zo onveranderd mogelijk.

[CurlyMo]

Vrijwel alle tabellen zijn zo gemaakt dat er nooit iets gewijzigd wordt, maar dat er een nieuw record met nieuwe informatie wordt toegevoegd.

[incaz]

Dan zou het kunnen. Maar ik benadruk nog wel eens: ga niet proberen om data waarvan je weet dat 'ie niet klopt toch in een veld te stoppen. Dat is het niet waard.