PostgreSQL: NULLs naar zero-length string

[Verwijderd]

Wanneer het niet nodig is om NULLs te gebruiken in databases, vermijd ik deze liever. Of je nu
select * from table where col=''
doet of
select * from table where col='' or col is null
moet doen, kan voor lange queries nogal uitmaken.

Wat ik me nu afvraag: Is het mogelijk om volautomatisch alle NULLs te laten omzetten in strings met lengte 0? Tuurlijk is dat mogelijk mbv plpgsql, maar om een of andere reden voel ik niet heel erg de behoefte om voor 25 tables met gemiddeld 8 rows triggers aan te gaan zitten maken. Niet alleen omdat het veel werk is, ook omdat het gewoon een rommeltje wordt in de dump.

Kan dat nou niet makkelijker? Bijv 1 parameter die aan de tabel/database gekoppeld kan worden, die het probleem transparant aanpakt, zoals "WITH OIDS" in postgresql 8?

[WormLord]

Je bedoeld dat je kolommen not-nullable wilt hebben, met een lege string als default waarde?
Tja, volgens mij kan postgresql dat wel aan ja, bij de kolom / tabel definitie.

[xos]

Je kan eens kijken naar de functie COALESCE

[Verwijderd]

WormLord schreef op zondag 01 juli 2007 @ 19:05:
Je bedoeld dat je kolommen not-nullable wilt hebben, met een lege string als default waarde?
Tja, volgens mij kan postgresql dat wel aan ja, bij de kolom / tabel definitie.

Ja, bijna. Dat kan postgresql inderdaad aan, maar ik bedoelde eigenlijk dat zélfs wanneer je expliciet zegt dat een waarde null moet worden, dat de database server dan lekker tóch een zero-length string invult.

xos schreef op zondag 01 juli 2007 @ 19:12:
Je kan eens kijken naar de functie COALESCE

Die functie was ik inderdaad tegengekomen, maar deze heeft bij het opvragen van de gegevens aanpassingen nodig. Ik wil juist dat het probleem bij het invoeren wordt ondervangen, en dat het transparant gebeurt - dus zonder aanpassingen aan de client SQL.

In plpgsql zou dat zijn:

code:

CREATE FUNCTION check_tabel() RETURNS "trigger"
    AS $$
    BEGIN
    IF NEW.veld IS NULL THEN
        NEW.veld='';
    END IF
        RETURN NEW;
        END;$$
    LANGUAGE plpgsql;

CREATE TRIGGER t_check_tabel
    BEFORE INSERT OR UPDATE ON tabel
    FOR EACH ROW
    EXECUTE PROCEDURE check_tabel();

maar dan volautomatisch, database-wide en zonder aan te hoeven geven voor welke tabellen, velden, nieuwe tabellen, toegevoegde velden etc.

Toch bedankt voor de suggesties.

[P_de_B]

Ik denk dat je je beter eens kunt verdiepen in wat een NULL-waarde betekent. NULL staat voor 'onbekend', en dat is iets heel anders dan een lege string, die twee moet je niet met elkaar vergelijken. Ik zou dus ook echt willen afraden dat je standaard alle NULLs door een lege string vervangt, ik zie ook echt niet waarom je dit zou willen.

[Verwijderd]

P_de_B schreef op zondag 01 juli 2007 @ 21:00:
Ik denk dat je je beter eens kunt verdiepen in wat een NULL-waarde betekent. NULL staat voor 'onbekend', en dat is iets heel anders dan een lege string, die twee moet je niet met elkaar vergelijken. Ik zou dus ook echt willen afraden dat je standaard alle NULLs door een lege string vervangt, ik zie ook echt niet waarom je dit zou willen.

En dat is dus precies wat ik niet wil. Geen niet-ingevulde waardes. En wil je perse toch een waarde leeglaten, dan moet het systeem dat invullen.

[Motrax]

Ik weet niet om wat voor type gegevens het gaat, maar bijvoorbeeld bij financiële gegevens zou dit een regelrechte ramp zijn.

Het verschil tussen NULL (niet bekend) en '0' is het verschil tussen het rond krijgen van je boekhouding of niet. Of het correct boeken van je purchase order enz enz

[P_de_B]

Verwijderd schreef op zondag 01 juli 2007 @ 21:15:
[...]


En dat is dus precies wat ik niet wil. Geen niet-ingevulde waardes. En wil je perse toch een waarde leeglaten, dan moet het systeem dat invullen.

Dan moet je een zinnige waarde vanuit de client weggeven. Wat als je de geboortedatum of het geslacht van iemand niet weet? Daar is een NULL goed voor. Waarom wil je wel een lege string, maar geen NULLs? Alleen omdat het wat typewerk bij een query scheelt? Dat is wel een hele slechte reden...

NULLs zijn goed, als je maar weet waar ze voor staan en hoe je er mee om wilt geen. Degene die geen NULLs in hun database toestaan vanuit een soort overtuiging kunnen beter met hun handen van een database afblijven.

[Gomez12]

Verwijderd schreef op zondag 01 juli 2007 @ 21:15:
[...]


En dat is dus precies wat ik niet wil. Geen niet-ingevulde waardes. En wil je perse toch een waarde leeglaten, dan moet het systeem dat invullen.

Als jij het niet wilt hebben zou ik het gewoon in je front-end opvangen. Als je het goed opvangt in je frontend, dan zou het niet meer in je dbase mogen staan.

Staat het toch in je dbase dan is er iets onbekends gebeurt... Dus dan klopt het wederom.

[Verwijderd]

Gomez12 schreef op zondag 01 juli 2007 @ 21:34:
[...]

Als jij het niet wilt hebben zou ik het gewoon in je front-end opvangen. Als je het goed opvangt in je frontend, dan zou het niet meer in je dbase mogen staan.

Staat het toch in je dbase dan is er iets onbekends gebeurt... Dus dan klopt het wederom.

Dan is het niet transparant.
En er is al lang over nagedacht. Ik heb niet veel aan argumenten waarom ik het niet zou mogen gebruiken, wel aan een suggestie hoe dit aan te pakken.

[P_de_B]

Nou ja, je moet het zelf maar weten.

De enige manier om dit te doen zoals jij wilt is het niet toestaan van NULLs, op geen enkele kolom. Je zult dan vanuit de frontend iets mee moeten geven, als je automatisch wilt dat er lege strings komen te staan moet je een default waarde in de database instellen.