Hej,
sitter på ett projekt där jag tror vi kan vinna mycket tid genom att optimera databasen. Jag kan grunderna i SQL men när det gäller optimering så är jag lite osäker. Det är server enterprise 7.0 som används.

Om jag sparar ett tal (tex 1,4) så sparas det i en varchar med storleken 50 tex. Innebär det att för varje tal som sparas så konverteras talet om till en sträng och sparas ner på en plats för 50 tecken?
Då innebär det ju att man skulle spara rätt mycket arbete och tid bara genom att spara tal som tal?

Är det i ett liknande fall där en max 5 tecken lång sträng sparas i ett 50 tecken långt fält viktigt att sätta maxlängden till fältet kortare?

Samma med precision, om jag har precision 4 sparas alltid 4 decimaler och gör det stor prestanda skillnad att minska till det man maximalt behöver?

Det finns två tabeller där det alltid görs ett urval på både datum kolumnen och en annan kolumn (sträng). Detta är väl ett skol exempel på när man ska indexera men ska det vara ett unikt index eller ett clustered och hur utyttjar jag indexet i mina querys?

Jag antar att man kan spara mycket tid på att använda stored procedures på dessa tabeller med?

Ska du spara enbart tal ska du spara det i en variabel för tal. Tal är mycket snabbare att söka på och det tar mycket mindre plats. En varchar är av varierande längd och enbart så många tecken som behövs, upp till det maximala antalet, reserveras. Så sparar du fyra tecken långa strängar i varchar(50) tas bara fyra tecken upp, i teorin. I praktiken måste det finnas något sluttecken eller annan metadata som beskriver hur lång din sträng är.

Indexera på alla Foreign Keys och fält du söker mycket på, det är min rekommendation.

När det gäller talen som sparas i ett varchar fält så söks det aldrig på dem (och kommer inte att göras i framtiden heller) så då kanske det inte ger så mycket (annat än personlig tillfredställelse att det är korrekt) att ändra dem.

Är det någon som har något bra och hyggligt lättläst länk som förklarar indexering och Stored procerures? De sajter jag varit inne på är antingen för grundläggande eller för abstrakta.

Troligen ligger prestandaproblemen i att det saknas Index. 9 gånger av 10 är det så.. Minst :)
Visst är det lämpligt att lagra tal som tal, men om du i detta fall i huvudsak läser från databasen och talet bara är en kolumn som visas upp, så kommer du inte märka av någon direkt prestandavinst genom att ändra på datatypen. Du bör göra det ändå, tycker jag, men av andra skäl.. :)
Sätt helt enkelt vanliga index på de fält som används i sökningar (where, join..)
Du behöver inte skriva något i din SQL för att indexen skall utnyttjas.
Detta sköter databasen automatiskt.
Clustered Index betyder att posterna kommer lagras fysiskt i denna ordning. Det kan bara finnas ett sådant index i en tabell, vanligen och default när du skapar en identity column (primärnyckel) är denna integer 4 bytes och clustered. Stored Procedures är bra men har du stora prestandaproblem löses inte dessa med att du konverterar inline/AD-Hoc-SQL till SP:s. SP:s är framför allt bra för att du kan separera SQL från t.ex. VB-kod, och du får ett mer strukturerat system som är enklare att underhålla.
SP:s har prestandafördelar (t.ex.databasen slipper kompilera SQL-strängarna som kommer in) men den faktorn blir sällan en flaskhals..

Det är alltid god databasdesign att använda sig av rätt datatyp på fältet. Dessutom blir det mer data att lagra om du vill lagra tal i siffror. Med 4 byte i en int kan du lagra ca 10 siffror. Ska du lagra 10 siffror i en varchar använder du dig av 10 byte + metadata.

Om du dessutom ska utföra någon typ av matematisk beräkning eller liknande på fältet blir detta inte möjligt om du lagrat i fel format, om du inte konverterar om fältets typ i SQL satsen på något sätt (vilket i så fall är väldigt prestandakrävande).
Vid sortering på tal sparat i en varchar får du också fel resultat. 1, 2, 10, 20 blir till exempel 1, 10, 2, 20.

Har inget uppslag på bra information om index och stored precedures, så det får någon annan tipsa om.

Men om jag har följande tabell

Datum Sträng andra värden som endast läses
39100 A
39099 B
39099 A
39098 B
39098 C
39098 A


Datumet sparas som tal, sökningarna görs alltid på både datum och strängen, DVS datum > date och datum < date och sträng = s.
Då bör jag indexera datum och strängen som clustered?

Om detta är en ReadOnly-tabell och man alltid söker på dessa två fält, då skulle det kunna fungera ja. Isf gör du ett sammansatt index på dessa två fält och gör det clustered. Men kom ihåg att det då måste vara unika värden. Om du börjar inserta värden mitt i kommer det bli mycket segt. Men detta kan vara bra om tabellen är ordentligt stor, det är bara readonly och man söker alltid på indexet (du sparar utrymme).