At vælge den rigtige felt størrelse

Hvis du ved at dine string højest vil være X tegn og X <= 4000, så bør
du bruge nvarchar(4000).

Både med nvarchar og ntext bruger du kun plads for den faktiske kængde ikke
for den maksimale længde.

nvarchar vil være hurtigere end ntext. Hvor meget præcist er svært at sige.

Der vil næppe være den store forskel på RAM forbrug uanset hvad du vælger.

Jeg faldt iøvrigt lige over følgende artikel:
  http://www.databasejournal.com/features/mssql/article.phpr/2212141

Du bør begrænse dine tekst-felter mest muligt. Der er en øvre grænse på poststørrelse på ca. 8000 tegn. Vurder alle felter og find den sandsynlige største tekst, der skal i et givet felt.

Desuden, hvis du har felter, der altid er x antal tegn (f.eks ISO valutakode (3 tegn)), er det en fordel at bruge char(x) eller nchar(x). Med varchar kan du komme ud for reference pointers, hvis indholdet ændres til mere end det først gemte.

Forskellen på nchar og char er unicode. nchar (og nvarchar) kan gemme unicode tegn, men det forøger feltstørrelsen til det dobbelte.

Vælg altid den mindste felttype som matcher dine behov. Sørg altid for, at din row-længde er mindre end 8Kb - SQL server tillader at du definerer længere rækker - men indsættelse og opdatering vil fejle når data når over 8Kb.

Blob (Binary Large Objects - altså ntext, text, etc) bør undgås, bl.a. fordi den felttype ikke kan indexeres. Selve håndteringen af blob felterne er også langsommere idet de foregår i et specielt memory område og ikke sammen med de øvrige felter i rækken. Der er i øvrigt et leak i dette område som over tid vil gøre at blob-behandling fejler (kan p.t. ikke huske om det er patchet).

Ved brug af CHAR fremfor VARCHAR - vær opmærksom på, at et CHAR altid fylder den definerede længde, den bliver reelt set udvidet med blanktegn til max længde. VARCHAR indeholder kun de indtastede data. Eks.

VARCHAR(5) = 'OLE'
CHAR(5) = 'OLE  '

Det har lidt betydning i en where-betingelse...

raos>

Tid at lukke spørgsmålet ?

Hey,

Hvad gør man så hvis man står i en situation hvor man har brug for et tekstfelt på fx. 16.000 tegn istedet for de max. 8000 der er?

1)  fortæller programmørerne at de kun har 8000
2)  splitter i 2 VARCHAR felter
3)  skifter fra VARCHAR til TEXT

Korrekt forstået at TEXT kan indeholde voldsomt mange tegn - eller vil du have at man tager to VARCHAR felter og splitter dem sammen til én variablen ved output som så præsenteres?

TEXT kan indeholde 2 GB.

2 VARCHAR som man konkatanerer i applikationen er også set som workaround.

Men 2 varchar på hver 8000 tegn kan ikke lagres i en række - det skal være i to rækker.  Max længden er stadig 8k for en enkelt row.