En rapport visar tomma kundnamn trots att e-postadressen finns, eller så blir en totalsumma NULL när ett fält saknas. Då kan COALESCE i SQL välja det första värdet som inte är NULL, men resultatet beror också på datatyperna och på vad du menar med ”saknas”.
COALESCE väljer första värdet som inte är NULL
- Ordningen styr resultatet: uttrycken prövas från vänster till höger.
- Alla värden är NULL: då returnerar COALESCE NULL, om du inte lägger till ett reservvärde.
- Tom text är inte automatiskt NULL: COALESCE ersätter den därför inte i vanliga databassystem.
- Datatyper spelar roll: argumenten måste kunna förenas till en kompatibel resultattyp.
- SQL Server har en viktig skillnad: COALESCE och ISNULL kan ge olika datatyp och nullbarhet.
COALESCE följer en tydlig prioriteringsordning
Tänk dig en kundtabell där ett visningsnamn kan komma från profilnamn, fakturanamn eller e-postadress. Med COALESCE anger du den ordningen direkt: det första värdet som inte är NULL vinner.
SELECT
COALESCE(profile_name, billing_name, email) AS display_name
FROM customers;Om profile_name är NULL används billing_name. Är även det NULL blir e-postadressen reservvärdet. Jag tycker att uttrycket blir lättläst när prioriteringen motsvarar en faktisk regel i verksamheten, inte bara råkar vara en praktisk ordning.
Om samtliga argument är NULL blir resultatet också NULL. Lägg till ett sista reservvärde när rapporten behöver visa något i stället:
COALESCE(profile_name, billing_name, email, 'Okänd kund')Tomma strängar och nollor kräver egna regler
En vanlig fallgrop är att behandla ”inget synligt värde” som samma sak som NULL. COALESCE reagerar på NULL, inte på en tom sträng eller värdet 0. Om en profil innehåller '' går funktionen alltså inte vidare till fakturanamnet.
COALESCE(NULLIF(profile_name, ''), billing_name, email)NULLIF(profile_name, '') omvandlar en tom sträng till NULL, så att nästa alternativ kan användas. För numeriska fält bör du däremot inte göra om noll till NULL utan att det speglar datans betydelse: ett lagersaldo på 0 kan vara ett korrekt värde, inte saknad information.
Den skillnaden avgör om reservvärdet fungerar som tänkt. Saknat, tomt och noll är tre olika tillstånd tills din fråga uttryckligen behandlar dem på samma sätt.
Argumenten måste passa ihop i datatyp
Två kolumner kan båda innehålla namn men ändå ha datatyper som databasen inte kan kombinera utan konvertering. PostgreSQL kräver att argumenten kan omvandlas till en gemensam typ, medan reglerna för resultattyp kan variera mellan databassystem. Därför är ett uttryck som blandar text och tal en möjlig källa till fel eller oväntad typ.
COALESCE(discount_text, 0)Om kolumnen är text och reservvärdet ett heltal bör du bestämma vilken typ resultatet ska ha och konvertera uttrycken tydligt, exempelvis med CAST. Det gör avsikten synlig och minskar risken för att databasen väljer en typ som inte passar efterföljande beräkningar. I PostgreSQLs dokumentation om villkorsuttryck beskrivs kravet på en gemensam datatyp.
För en rapportkolumn med pengar kan ett uttryck som COALESCE(discount, 0.00) vara rimligt när båda uttrycken har en kompatibel numerisk typ. Blandar du däremot textvärden och belopp kan du behöva konvertera uttrycken innan du använder funktionen.
COALESCE och ISNULL kan ge olika resultat i SQL Server
Två uttryck kan visa samma värde i en enkel SELECT men ändå skilja sig när de används i en beräknad kolumn eller ett index. I SQL Server följer COALESCE typreglerna för CASE, medan ISNULL normalt använder datatypen från sitt första argument. Även databasens bedömning av om resultatet kan vara NULL skiljer sig.
| Situation | Vad kan hända? | Vad du kan göra |
|---|---|---|
| Du behöver flera reservvärden | ISNULL tar två argument; COALESCE kan ta flera. |
Använd COALESCE(a, b, c) när alternativen ska prövas i ordning. |
| Argumenten har olika datatyper | Resultattypen kan skilja sig från den typ du väntar dig. | Kontrollera typreglerna och använd vid behov uttrycklig CAST. |
| Uttrycket ska ingå i en nyckel eller beräknad kolumn | SQL Server kan bedöma nullbarheten annorlunda för de två uttrycken. | Verifiera definitionen mot kraven för kolumnen eller indexet innan du väljer funktion. |
| Ett argument innehåller en subfråga | I SQL Server kan COALESCE-uttryck utvärderas flera gånger. | Undvik att förutsätta en enda utvärdering om subfrågan kan ge varierande resultat. |
Den sista raden är lätt att missa: Microsoft beskriver att ett COALESCE-uttryck i SQL Server kan utvärdera ett argument flera gånger, bland annat när argumentet innehåller en subfråga. Om resultatet måste vara stabilt kan en omstrukturering, exempelvis att först hämta delresultatet i en separat fråga, vara säkrare. Det här är en SQL Server-specifik detalj, inte en generell regel för alla databaser, och Microsofts dokumentation om COALESCE i Transact-SQL beskriver även skillnaderna mot ISNULL.
Välj funktion efter databas och betydelse
Behöver du ersätta NULL med ett reservvärde i en fråga som ska fungera i flera databasmiljöer är COALESCE ofta ett tydligt förstaval. Funktionen finns bland annat i PostgreSQL, Oracle och MySQL, men detaljer om datatyper och utvärdering är inte identiska. Portabel syntax betyder inte att alla kantfall är portabla.
| Situation | Möjlig orsak | Nästa steg |
|---|---|---|
| Reservtexten visas inte | Kolumnen innehåller tom text i stället för NULL. | Använd NULLIF om tom text ska räknas som saknad. |
| Frågan ger typfel eller fel format | Argumenten har typer som inte kan förenas som väntat. | Kontrollera kolumntyperna och konvertera uttrycken uttryckligen. |
| En beräkning ger NULL trots ett saknat värde | Reservvärdet kan saknas, eller ett annat uttryck kan fortfarande vara NULL. | Följ uttrycket stegvis och hantera varje fält som får ersättas. |
| Beräknad kolumn eller index godkänns inte | SQL Server kan bedöma COALESCE-uttryckets nullbarhet som nullable. | Kontrollera kravet på nullbarhet och jämför med ISNULL om frågan körs i SQL Server. |
Min tumregel är enkel: välj COALESCE när du behöver en tydlig kedja av flera alternativ, och kontrollera typen när argumenten inte är likadana. Om uttrycket ska användas i SQL Server som del av en nyckel eller beräknad kolumn, kontrollera även nullbarheten innan det går vidare till produktion.
En bra reservregel börjar med vad NULL betyder
Innan du lägger till ett standardvärde, fråga vad NULL står för i just den kolumnen. NULL kan betyda att uppgiften inte samlats in, ännu inte är känd eller inte gäller; de betydelserna bör inte alltid bli samma text eller siffra i en rapport.
För ett kundkort kan ett reservnamn hjälpa läsaren att förstå att uppgiften saknas. För ett belopp kan noll däremot antyda att värdet är känt och faktiskt är noll. Välj därför reservvärdet utifrån datans betydelse, inte bara för att få bort NULL ur resultatet.