[MySQL] NULL != %%

[me1299]

Ik heb een bestaanden database plus website waarin een foutje zit. Er wordt een query gedraait om een aantal documenten boven water te toveren.

Bij een WHERE operator staat:

code:

documenten.titel LIKE '%%'

Met andere woorden match alles, alleen nu zijn er documenten waarbij het titel veld op de waarde NULL staat, deze worden dus niet gematched. Is er een manier om deze toch ook te matchen of moet er dan perse een extra OR bij komen waarin ik vermeld dat NULL ook gematched moet worden?

[P_de_B]

NULL is per definitie ongelijk aan alles. Je moet dus apart iets matchen. Kijk eens naar COALESCE

[Remus]

Mogen documenten in jullie domain model eigenlijk wel geen titel hebben? Misschien is dit een indicatie van een fout in het model, en moet je evt afdwingen dat een NULL titel niet mag.

BTW: Als je alle documenten wilt, waarom wordt er dan uberhaupt een conditie toegevoegd op 'de titel mag alles zijn'?

[YakuzA]

In dit specifieke geval zou je gewoon deze constraint niet in de where moeten zetten.

[me1299]

Ja hoor een titel is optioneel daar de documenten ook via andere parameters te indexeren zijn. Ik heb het probleem inmiddels eenvoudig opgelost door de default waarde geen NULL te geven maar gewoon "".

Bedankt voor het meedenken.

[RobIII]

DeathKnight24 schreef op donderdag 11 augustus 2011 @ 12:08:
Ja hoor een titel is optioneel daar de documenten ook via andere parameters te indexeren zijn. Ik heb het probleem inmiddels eenvoudig opgelost door de default waarde geen NULL te geven maar gewoon "".

Fout.

Null == Geen waarde gespecificeerd voor dit veld. En dat is iets anders dan een lege string wat wél een waarde is, namelijk een lege string.

Zoals gezegd had je beter gewoon COALESCE kunnen gebruiken (of ISNULL of... net wat je RDMBS daarvoor gebruikt).

[me1299]

Een lege string vind ik ook prima

[RobIII]

DeathKnight24 schreef op donderdag 11 augustus 2011 @ 12:23:
Een lege string vind ik ook prima

Dat zal best, maar 't is niet 'tzelfde. Je hebt dus functioneel iets gewijzigd hoewel je in de waan bent iets gefixed te hebben. Misschien wat 't al fout in-the-first-place en waren de NULL values helemaal niet de bedoeling en is je fix inderdaad correct. Maar misschien ook wel. All I know is dat ik een datamodel (waar doorgaans, niet altijd) toch goed over nagedacht is niet zo 1-2-3 en zo simpel zou verbouwen als je nu hebt gedaan (althans: dat is de indruk die je wekt). Het is namelijk geen oplossing maar symptoombestrijding. En wie weet heb je nu wel meer stuk gemaakt dan je denkt.

[me1299]

Het klopt inderdaad dat oude waardes niet NULL moesten zijn. Het systeem heeft namelijk recent een update gehad en sindsdien werkte het niet meer naar behoren.

Oude waarden in de database waren leeg en niet NULL. Dus het is nu zoals het ooit bedoeld is.

Ik begrijp het verschil tussen NULL & '' volledig en besef de consequenties voor eventuele insert queries.

[NMe]

Je hebt dus een ranzige wijziging in je data gemaakt om zo een where-clause mogelijk te maken die niets doet behalve je query langer maken (de query optimizer filtert hem vast weg)? Handig!

[me1299]

Het zou inderdaad beter zijn dat deze WHERE clause helemaal niet gebruikt wordt op het moment dat er niet gefilterd wordt op een omschrijving.

Maar gelukkig heb jij tijd om alle code die je niet zelf geschreven hebt te verbeteren als dat niet facturabel is

[ Voor 29% gewijzigd door me1299 op 11-08-2011 12:42 ]

[NMe]

DeathKnight24 schreef op donderdag 11 augustus 2011 @ 12:42:
Het zou inderdaad beter zijn dat deze WHERE clause helemaal niet gebruikt wordt op het moment dat er niet gefilterd wordt op een omschrijving.

Maar gelukkig heb jij tijd om alle code die je niet zelf geschreven hebt te verbeteren als dat niet facturabel is

Je kan verdorie gewoon alles laten staan, het enige dat je hoeft te doen is documenten.titel veranderen in COALESCE(documenten.titel, '') en je bent er, alles blijft werken zoals het altijd deed met bijkomend voordeel dat NULL-waardes gewoon werken. In plaats daarvan heb je de meest ranzige oplossing gebruikt die er maar te vinden is voor dit probleem en als je daarop gewezen wordt kom je met die cynische ondertoon? Doe eens niet.

[ Voor 6% gewijzigd door NMe op 11-08-2011 13:34 ]

[RobIII]

NMe schreef op donderdag 11 augustus 2011 @ 13:33:
[...]

Je kan verdorie gewoon alles laten staan

Wat ik er uit lees is dat 'ie een update die de zooi "gebroken" heeft nu juist heeft gefixed door die NULLs niet meer toe te staan:

DeathKnight24 schreef op donderdag 11 augustus 2011 @ 12:33:
Het klopt inderdaad dat oude waardes niet NULL moesten zijn. Het systeem heeft namelijk recent een update gehad en sindsdien werkte het niet meer naar behoren.

Dat is ook precies de reden waarom ik een beetje een slag om de arm hield

Neemt niet weg dat ik eerst even die COALESCE had gebruikt tot ik zeker wist dat 't niet-NULLs-toestaan de juiste oplossing was. En dat ik 't verdraaid vreemd vind dat dit topic überhaupt bestaat. TS had namelijk al meteen in de gaten dat 't met NULLs mis ging en toen er een oplossing kwam waren opeens de NULLs verkeerd.

[ Voor 30% gewijzigd door RobIII op 11-08-2011 13:38 ]

[NMe]

RobIII schreef op donderdag 11 augustus 2011 @ 13:36:
[...]

Wat ik er uit lees is dat 'ie een update die de zooi "gebroken" heeft nu juist heeft gefixed door die NULLs niet meer toe te staan:

[...]

Dat is ook precies de reden waarom ik een beetje een slag om de arm hield

Ja, maar intussen staan er dus wel al NULL-waardes in de database die nu vervangen zijn door lege strings. Voor iets als een titel zijn ze beiden niet handig maar het onderliggende probleem los je in beide gevallen niet op...

Zie ook dit trouwens:

DeathKnight24 schreef op donderdag 11 augustus 2011 @ 12:33:
Oude waarden in de database waren leeg en niet NULL. Dus het is nu zoals het ooit bedoeld is.

Dan is het dus ooit fout bedoeld, want lege waarden horen geen lege strings te zijn. Geen titel = null. Die update heeft dus een onvolkomenheid gefixt die nu weer geherintroduceerd is omdat de topicstarter liever geen coalesce wil gebruiken?

[ Voor 27% gewijzigd door NMe op 11-08-2011 13:40 ]

[ValHallASW]

NMe schreef op donderdag 11 augustus 2011 @ 13:38:
Dan is het dus ooit fout bedoeld, want lege waarden horen geen lege strings te zijn.

Dat klinkt leuk, maar het levert wel een vrij fundamenteel probleem op: hoe toon je dat aan de gebruiker? Een leeg tekstveld kan immers twee dingen betekenen: NULL of een lege string (itt bijvoorbeeld een vakje waar een telefoonnummer of een getal inmoet, daar betekent een leeg vakje duidelijk NULL) - en de vraag is of je je gebruiker daar mee lastig wilt/moet vallen.

Toegegeven, in dit geval betekent een leeg vakje hoogstwaarschijnlijk 'geen data beschikbaar', maar dat /hoeft/ niet: je kunt best een document zonder titel maken.

[ Voor 12% gewijzigd door ValHallASW op 11-08-2011 14:09 ]

[me1299]

Ik begrijp dat er een onderscheid bestaat tussen geen omschrijving hebben en een lege omschrijving. Nu ben ik het mondig met je eens dat het eigenlijk niet 100% correct is op deze manier. Maar ik moet soms een afweging maken tussen veel aanpassingen maken die tijd kosten maar voor de werking van het systeem niet veel uit maken, of een quick (dirty) fix die binnen korte tijd te realiseren is zonder dat de werking van het systeem in het geding komt.

In dit geval heeft iemand die de query heeft geschreven dus een aantal selecties gemaakt met select tabel.* (ja vies en traag enz enz). Dit zou dus betekenen dat ik de query voluit moet herschrijven waarvoor ik alle relevante kolommen in de database moet gaan nazoeken.

Het eindresultaat zou sneller mooier en beter te onderhouden zijn, dat zal ik zeker niet ontkennen maar uiteindelijk is het niet facturabel en zodoende kan ik mijn tijd beter nuttiger besteden.

Een klant wil vaak een website die werkt, of het op de achtergrond zeer netjes werkt zal hem zijn reet roesten. Wel probeer ik bij nieuwe projecten van te voren dit soort onvolkomenheden van te voren te vermijden. Dit is dan ook een oud project wat niet door mij geschreven is.

[NMe]

In dat geval wens ik je veel plezier als straks iemand op de een of andere manier alsnog een nullwaarde weet te inserten. Tenzij je het veld ook "NOT NULL" hebt gemaakt maar dan zit je dus écht symptomen te bestrijden waar de "schone" oplossing twee minuutjes meer werk was geweest. Maar goed, jouw feestje.

[Voutloos]

DeathKnight24 schreef op donderdag 11 augustus 2011 @ 14:09:
Het eindresultaat zou sneller mooier en beter te onderhouden zijn, dat zal ik zeker niet ontkennen maar uiteindelijk is het niet facturabel en zodoende kan ik mijn tijd beter nuttiger besteden.

Maar ja, kan je wel het extra onderhoud en de nodige fixes als je pleistertje faalt factureren?

[GlowMouse]

ValHallASW schreef op donderdag 11 augustus 2011 @ 14:08:
[...]


Dat klinkt leuk, maar het levert wel een vrij fundamenteel probleem op: hoe toon je dat aan de gebruiker? Een leeg tekstveld kan immers twee dingen betekenen: NULL of een lege string (itt bijvoorbeeld een vakje waar een telefoonnummer of een getal inmoet, daar betekent een leeg vakje duidelijk NULL) - en de vraag is of je je gebruiker daar mee lastig wilt/moet vallen.

Precies, en met de oorspronkelijke invoer heb je hetzelfde probleem, tenzij je het titelinvoervakje alleen toont als de gebruiker op een extra knopje drukt dat hij een titel toe wil voegen.

NMe schreef op donderdag 11 augustus 2011 @ 12:37:
Je hebt dus een ranzige wijziging in je data gemaakt om zo een where-clause mogelijk te maken die niets doet behalve je query langer maken (de query optimizer filtert hem vast weg)?

Hij wordt niet weggefilterd, anders zou hij NULL-values ook matchen.

[Verwijderd]

Zijdelings offtopic:

Oracle heeft in haar oneindige wijsheid besloten dat lege strings ('') worden opgeslagen als NULLs. Altijd lachen, en zorgt absoluut niet voor frustratie en onverwachte uitkomsten.

[Aloys]

Was het zetten van de document.titel op NULL niet toevallig een nieuwe "feature". Waarmee je dus documenten "onzichtbaar" kon maken (hoewel het wel ranzig is).

Probleem waar je nu mee komt te zitten is dat bij de volgende update je waarschijnlijk weer alles moet "fixen" omdat dan weer NULL wordt gebruikt

[Remus]

Aloys schreef op donderdag 11 augustus 2011 @ 16:21:
Was het zetten van de document.titel op NULL niet toevallig een nieuwe "feature". Waarmee je dus documenten "onzichtbaar" kon maken (hoewel het wel ranzig is).

Probleem waar je nu mee komt te zitten is dat bij de volgende update je waarschijnlijk weer alles moet "fixen" omdat dan weer NULL wordt gebruikt

Dat lijkt mij op zich weer een ranzige manier van documenten onzichtbaar maken