Pladsforbrug med MsSql

1 tegn = en byte. Men nogle af datatyperne bruger også noget på at gemme og indeksere. Jeg kan ikke helt huske det. Det er lang tid siden jeg har haft SQL undervisning. Men brug altid kun det du har brug for at de forskellige typer. Ved ikke om det er til noget hjælp men her er til MySQL burde næsten være det samme:
http://www.mysql.com/doc/en/Numeric_types.html og
http://www.mysql.com/doc/en/String_types.html

Jeg ved godt alt det med hvad data der er i databasen og sammenholdet mellem pladsforbruget og hvilke tal der er tale om.

Det jeg brænder efter at vide er overhead. Eller rettere, hvormeget fylder mine data på disken. Dermed også indexsering, som jeg endda havde glemt :-)

Hvis man fortsætter med at benytte MySQL som eksempel, burde du prøve at kigge på følgende:
http://www.mysql.com/doc/en/Storage_requirements.html
http://www.mysql.com/doc/en/CHAR.html

Som kan ses, fylder char(50) 50 bytes - men er samtidig udfyldt med mellemrum, og fylder hele tiden 50 bytes, ligemeget hvor meget data der er i.
Derimod varchar(50) fylder min. 1 og max. 51 bytes. Hvis du f.eks. udfylder 10 tegn ud af de 50, bruger du dermed kun 11 bytes.
Ved ikk om du kan se sammenhængen?!

Ang. det med "overhead" - det kommer hurtigt, hvis du f.eks. sletter en række (eller vidstnok også ændre, fx. skriver mindre i et tekstfelt - teoretisk set, anyway), så er det ikke altid at det hele bliver ryddet op. Du kan dog få databasen til at rydde/samle op, så at det overhead forsvinder.

Ja som stingbat siger så er char(50) 50 bytes. F.eks. i MySQL som vi begge godt kan lide så er der en der hedder varchar (ved ikke hvad den hedder i MS) men den varierer størrelsen alt efter hvad du ligger i eller hvor stor du sætter den til.

MsSQL gemmer data i 8K blokke (pages), og da en række ikke kan deles mellem 2 pages, så er det en faktor du skal have med. Faktisk kan ikke alle 8K i en page bruges til data, der er lidt blok/link info her også. På indeks kan du sætte fyldingsgraden så du bestemmer hvor meget fri plads du vil efterlade på den enkelte page.

Pages gemmes i extents - 64K blokke - og det er den størrelse der altid læses/skrives ad gangen. I mindre tabeller kan indeks information dele extents med tabel-data, i større sker det (normalt) ikke. En page deles ikke.

Du kan ganske nemt beregne hvor stor en given tabel *kan* blive pr række - alle de nødvendige informationer står i viewet SYSTEM_INFORMATION.COLUMNS. I Books Online (BOL) kan du så se hvor meget de enkelte datatyper fylder.

I beregning af pladsforbrug med variable datatyper (varchars, blobs (text/image) og varbinary) må du enten bruge max i beregningen eller den forventede fyldningsgrad. Så finder du ud af hvor mange hele rækker der kan være indenfor 8K og bruger det til at beregne den nødvendige plads til det forventede antal rækker + en sjat ekstra :-)

Mht sletning etc er det ikke noget problem - SQL Server rydder rimelig pænt op løbende, så plads genbruges uden det helt store. Man bør dog, fx månedligt ved aktive databaser, rebuilde indeks mv - ikke af hensyn til plads men af hensyn til hastighed.

Du kan kigge i tabellen dbo.sysindexes - i den finder du information om antal brugte pages, extents etc - beskrivelse af kolonner finder du også i BOL. Det er dog ikke ligetil at udlæse, der skal regnes lidt før tallene er anvendelige.

Bemærk at det at beregne pladsen til data ikke er nok. Hver transaktion ryger i databasens log. Benytter du simple recovery model skal transaktionsloggen være stor nok til den største transaktion der foretages på et givent tidspunkt - benytter du full recovery model (hvad jeg kun kan anbefale) skal loggen være stor nok til at indeholde samtlige transaktioner mellem to backups.

Databasen bør være sat til aldrig at udvide - dynamisk udvidelse og shrink får en server til at give r*vdårlig performance - og hvis du af en eller anden grund vil have udvidelse bør det være i hele antal megabytes. Check hvad antal megabytes dit disksystem er hurtigst til at oprette, og sæt det så til det. Ofte er en udvidelse med 25-50 MB ad gangen ok, det bør ikke være mindre.

Har du ikke nok ram i boksen vil sorteringer, joins etc ikke kunne holdes rent i ram, de vil blive swappet ned i TEMPDB - derfor skal den også være ganske stor.

styless:
Hedder skam også char og varchar under M$SQL

stingbat/styless> Det hænger sammen med, at MsSQL rimeligt overholder SQL92 standarden...

Mht datatyper - husk lige, at NVARCHAR er Unicode - dvs. 16bit pr tegn og NTEXT er det samme.

Og TEXT og NTEXT (faktisk blobfelter generelt) kan indeholde op til 2GB uden problemer... I tabellens række fylder de kun 16 bytes (en pointerstruktur) men i databasen har de deres rigtige størrelse...

Det er skam meget let, det med slettede poster, for dem har jeg ikke givet kunden mulighed for at lave :-)
Jeg kører med et felt i hver "linie", som med en bool afgøre om den er slettet eller ikke. Det gøres fordi nogle af de gamle data muligvis stadig bruge de "slettede" records. Desuden vil det sjældent forkomme at en record skal slettes.
Altså hvis en linie fylder 155 byte, så kan der være 52,85 linier på 8192 byte. Hvilket vil sige 52 linier, ved maks forbrug og det er så hvad jeg regner videre på. Hvor de 64M passer ind fik jeg ikke lige.
Det er ikke fordi data fylder så meget i min database. Jeg får bare en del linier med tiden.
Undre mig lidt at en varchar kun fylder én sølle byte ekstra, men siger i det, så er det rigtigt. Havde jeg været programmøren af en database, var jeg nok endt på mere :-)
trer : Mange tak for din flotte beskrivelse. Fuld point til dig for det :-)

Umiddelbart ville jeg mene, at en VARCHAR / NVARCHAR fylder mindst 2 bytes ekstra. Den kan have en længde på 8000 bytes (8000 / 4000 tegn), og det tal er mig lidt stort til en byte. Regn også hellere med max 8000 bytes pr page - dvs. max 51 rækker pr page.

De 64 kb er den størrelse sql server læser og skriver til disk i. Jeg havde en gammel oplysning liggende om, at forskellige objekter ikke kunne dele extents, men det er forkert, det kan de godt i dag.  Til gengæld fylder en tabel eller indeks altid mindst 2 pages.

Nu var det MySQL og dens varchar der blev snakket om - den fylder kun 1 byte ekstra.
Derimod når man har med text (og større) af gøre i MySQL, fylder de selvfølgelig mere.

Man kan vel bedre sammenligne varchar (MSSQL) med text (MySQL) - og i det tilfælde, er den 2 bytes ekstra. Det er først når man går op til større text-felter, at det fylder mere (>2).

Kan ikke huske hvordan og hvorledes med MSSQL - for længe siden jeg har arbejdet konkret med den.