Rent intuitivt tycker man att ett NULL värde i ett "större" fält, typ Text i Access eller varchar() i SQL Server borde ge prestandavinster i databasen jämfört med om man har ett defaultvärde och samtidigt inte tillåter NULL i kolumnen. NULL-värden i SQL Server är en delikat fråga ja. Generellt sett försöker jag undvika dem i möjligaste mån, men det är klart att i vissa fall är det dumt att ha en default istället. Vad man måste tänka på är att null-värden ofta behandlas annorlunda än 'riktiga' värden. Se ex. min artikel om COUNT()-funktionen för ett exempel på hur fel det kan bli (http://www.pellesoft.nu/login/articles/databas/count_prestanda.asp). För vanliga ej obligatoriska fält föredrar jag null istället för tom sträng. Har vant mig att access spara dem så.Defaultvärden eller NULL i kolumnerna?
INSERT, UPDATE & SELECT borde alla gå fortare med ett NULL värde ist.f. en tom eller expanderad blanksträng, "N/A", eller vad man nu har för NULL-värde.
Koden i ens VB-klient blir förstås lite längre, men som programmerare bjussar man gärna på det om man på köpet får fram vad man tror är en bättre lösning.
Vore mycket intresserad av att höra andras erfarenheter eller åsikter i ämnet använda eller inte använda NULL!Sv: Defaultvärden eller NULL i kolumnerna?
Vad gäller text-fält i SQL Server (jag räknar inte varchar som ett större fält) så blir det ännu mer speciellt med NULL-värden. Om vi bortser från att man i SQL Server 2000 kan använda en option som heter 'text in row' så lagras inte datan man skriver till ett text-fält tillsammans med den övriga datan i tabellen. Istället lagras endast en pekare till den riktiga datan, vilken sedan ligger lagrad i ett b-träd. Jag har inte riktigt lyckats komma fram till vad som egentligen lagras om man lägger in null i ett sådant fält (har iofs inte testat mycket heller) men jag kan tänka mig att den verkligen lagrar null och aldrig skapar nån pekare. Nedanstående kod verkar visa det. Den kommer ej att fungera om man inte avkommenterar update-satsen och kör den innan man försöker hämta sin textpointer.
use pubs
go
insert into publishers (pub_id, pub_name, city, state, country) values ('9912', 'Testpub', 'Boston', 'MA', 'USA')
go
insert into pub_info (pub_id) values ('9912')
go
select * from pub_info where pr_info is null
-- update pub_info set pr_info = NULL where pub_id = '9912'
DECLARE @ptrval VARBINARY(16)
SELECT @ptrval = TEXTPTR(pr_info)
FROM pub_info
WHERE pub_id = '9912'
WRITETEXT pub_info.pr_info @ptrval 'abcd'
select * from pub_info where pr_info is null
Vad jag försöker komma fram till är att man behöver nog inte fundera så mycket på prestanda när det gäller null-värden, utan det handlar mer om att man måste vara uppmärksam på vad det innebär att man har dem samt använda dem enbart när de har någon riktig mening.Sv: Defaultvärden eller NULL i kolumnerna?
Vad det gäller obligatoriska fällt bör det ju inte vara tomma, null. Eller för textfält "".
Vad det gäller främmande nycklar(foreign keys) är null ett bra redskap för att kuna bibehålla referensintegritet om en relation skall vara valfri för en post.