HUr skriver jag snabbast till en databas, och effektivast utrymmesmässigt??

130'000 poster i en sql-tabell är inget att bråka om, så länge den är vettigt indexerad (vilket är viktigt!) så har du gott om marginal.

Och ja, stored procedures är bättre ur prestandasynpunkt, då dessa i de flesta fall kan förkompileras. (dock inte om de innehåller t ex if-satser vad jag vet?)

350mb ska väl heller inte vara något problem i sig.

Om du vill ha mer konkreta tips så behöver vi nog få se databasstrukturen och sql-frågorna.

med databasstrukturen menar du vilka fält och vilka variabel typer då eller??

vet inte hur man eklast skriver ut strukturen från sql server managment studio express.. gjorde en print screen iaf... om det hjälper...

försöker skapa återkommande värden i andra tabeller och referera till dom via id, så man ska göra eller??

kollade lite. fältet referal innehåller adressen till sidan besökaren kom ifrån, ska man lägga detta i en egen tabell och referar till den tabellen istället? när är det lönsamt att göra så här?? e detta en relationsdatabas då?? jag grupperade alla poster ut efter referal fältet och fick då 1343 poster, totalt är det ju 130 000 poster.. annat exempel är resolution som krivs ut i tabellen men ska jag lägga över dom också till en annan tabell och hänvisa dit??

mvh

eddy1 skrev:

nu använder jag INSERT INTO... är det bättre om man skickar världen till en SP så den skriver allt till tabellen..

INSERT INTO kommer du att använda i vilket fall som helst ju :) Fördelarna med SP ska inte överdrivas, men i det här fallet känns det rimligt och smidigt att använda en dylik, eftersom SQL-frågan kommer att i princip likadan ut varje gång den körs.

eddy1 skrev:

Databsen är nu på ca 350mb.. Är det mycket??

Äsch då. Ingen fara.

eddy1 skrev:

tacksma för lite tips när man arbetar med databaser och det ska gå fort med hanska många poster... är väldigt dålig på detta:)

Det man ska tänka på är hur många INSERT som körs i förhållande till hur många SELECT. När man ska söka i stora datamängder så är man väl betjänt av att ha väldefinierade index, gärna flera skräddarsydda. En INSERT däremot lider av att indexen finns där. Den vill egentligen bara lägga till en rad och sticka därifrån, men om det finns index så måste även de uppdateras och det är mycket jobbigare.

Alla stora statistiksystem bygger på att data matas in på en enkelt och oavancerat sätt (jmfr. loggfiler på en webbserver). Man gör sedan grundläggande statistikberäkningar etc. innan man till slut för in informationen i en sökbar databas. Med andra ord, man gör aldrig några sökningar eller beräkningar direkt i den stora datamängden, utan bara i en skräddarsydd databas, där det mesta redan är beräknat. på så vis får man maximal prestanda på både INSERT och SELECT.

Tack för det väl skrivna svaret.. Även om jag inte förstår så mycket av det men jag är också ganska ny på det här...

Men min första tanke nu då är..
om man ser till tabellen där alla information sparas om besökaren, där har jag ju t.ex fältet "resolution" här står nu upplösning. jag provade att gruppera efter det fältet och det gav 272 olika poster.. Är det bättre att lägga dessa i en egen tabell och bara hänvisa med rätt id nr i fältet "resolution". Hade ju ett exempel till i tabellen, fältet "referal" innehåller 1500 unika poster??

Om jag nu ska spara en ny post med en Sp. Hur ska den se ut ungefär då?
det är ju nästan 10 olika värden som ska sparas och vissa måste ju kontrolleras om dom finns i andra tabeller eller om ett nytt värde ska läggas till för att sedan spara id'et i tabellen??

kanske är flumiga frågor, men som sagt.. Jag är relativt ny på detta..

eddy1 skrev:

om man ser till tabellen där alla information sparas om besökaren, där har jag ju t.ex fältet "resolution" här står nu upplösning. jag provade att gruppera efter det fältet och det gav 272 olika poster.. Är det bättre att lägga dessa i en egen tabell och bara hänvisa med rätt id nr i fältet "resolution".

Nej, det låter överflödigt. Även om man skulle kunna argumentera för det ur ett normaliseringsperspektiv skulle det varken bli snabbare eller mer lättförståeligt. Däremot är väl upplösning (antar att vi menar på skärmen) en sak som ska delas upp i två; bredd och höjd. Innehåller det nuvarande fältet en text som säger typ "1280x1024"? Det exemplet tar gissningsvis upp 9 eller 18 byte i din databas (+ ev. overhead). Istället skulle du kunna ha det som två unsigned heltalsfält på vardera två bytes (om man gör rimliga antagandet att ingen skärm kommer vara större än 65535 pixlar i bredd eller höjd), och bums använder du mindre minne, får snabbare skriv- och lästider, mindre risk att få in skräp i databasen, etc.

red. Kollade på din modell och såg att det var som jag misstänkte. Använd aldrig ett textfält om det du ska lagra är numeriska värden :)

ok...
så då ska jag ha två fält istället då, ett höjd och ett för bredd.. Du har rätt. Jag skriver ut upplösning i det fältet, ex "1280x1024" ... ska försöka skriva om det då:) tack för det..

När man väljer variabel typer så brukar jag alltid välja ex: varchar(100) när det gäller text.. 100 anger väll alltid tecken? är dte rätt sätt eller finns dte ngt bättre??

men sen fältet referal då som innehåller domänen besökaren kom ifrån, det fältet är väll av typen varchar(100). när jag grupperade det så innehöll det ca 1500... ska det vara en egen tabell??

några andra tips vad dte gäller variaeltyper i databasen??

mvh

eddy1 skrev:

När man väljer variabel typer så brukar jag alltid välja ex: varchar(100) när det gäller text.. 100 anger väll alltid tecken? är dte rätt sätt eller finns dte ngt bättre??

Det beror på. CHAR brukar ofta kunna vara lite snabbare än VARCHAR eftersom det alltid har maxlängd på fälten, men å andra sidan är VARCHAR mer ekonomiskt med minnet.

eddy1 skrev:

men sen fältet referal då som innehåller domänen besökaren kom ifrån, det fältet är väll av typen varchar(100). när jag grupperade det så innehöll det ca 1500... ska det vara en egen tabell??

Att ett värde förekommer flera gånger i samma tabell är helt i sin ordning. Antag att man gör ett personregister över alla Sveriges innevånare. Man skulle inte göra "kön" till en egen tabell bara för att hälften av alla poster skulle ha samma värde :)

ok. kanske inte ska stirra mig blind på det då:)

Hur är det nu då med SP? Ska jag lägga över hela INSERT INTO strängen till en SP som sköter det. kan det minska fördröjningen för besökaren när posten ska läggas till eller??

Någon annan, som är mer insatt i SQL Server, kan ju uttala sig med mer säkerhet om saken, men jag har svårt att se hur mycket man kan vinna på att ha en insert som SP, eftersom exekveringsplanen för en vanlig insert är ytterst trivial. Men en idé är ju att du skriver ett test och tar reda på det själv, låter inte det smart? :)

kan man mäta tiden på ngt sätt... jag har gjort en sp och lagt om all kod där i.... ändå bara svårt att se med blotta ögat, när det bara handla om ngn sekund :)

Sätt upp en trace med SQL Server Profiler (om det nu ingår i express-utgåvan - det vet jag inte.)

Finns i Tools-menyn.

Verkar inte som det går i express?? fanns inget sådant alternativ....

Du kan ju också prova att göra en massa anrop av SP:n från ett program och skriva ut vad klockan är före resp. efter anropen...