hurtig insert

Hvordan sender din applikation forespørgslerne? Som en lang SQL streng eller a flere omgange.

Hvad er din applikation skrevet i.

Den hurtigste måde jeg kender er at bruge prepared statements:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/adosql/adoprg02_97qr.asp

Hvad med at lægge dine inserts i en transaktion? Det skulle gerne optimere processen.

Det er business logic kodet i Visual basic. Prepare giver vel ikke så meget. Men en transkation ville vil give en hel del eller hvad?

Det burde hjælpe - det er jo en caching af operationer som bliver optimeret før udførslen.
Det er rimeligt let at implementere - så jeg kan kun anbefale at du prøver det.

En transaktion giver IKKE noget! Det eneste en transaktion gør er at holde styr på det der er ved at blive indsat.. ikke andet.
En prepared statement er compilet, så i efterfølgende inserts, er det kun nødvendigt at overføre data.
Et andet 'trix' er også at lave fx:
sp_insertdata 'data1', 'data2';sp_insertdata 'data3', 'data4' osv....

Så minimerer man den tid det tager at initiere forbindelsen fra VB til databasen. Bemærk at man kun kan sende 8000 (så vidt jeg husker) karakterer med en almindelig statement i ado...

PS: Hvis din SQL Server har begrænset hukommelse kan det anbefales at du laver "pakker" af inserts i en transaktion, f.eks. 50 ad gangen.

_just4fun_ >> Gør transaktionen ikke at jeg først giver den al informationer, for derefter at udføre den?

Hhis jeg kan give den alle informationerne i et kald, og derefter et kald med "commit" så er det vel hurtigere, eller hvad?

Afhængig af hvormange inserts vi snakker kunne et kig på OPENXML også være relevant:

http://www.sql-server-performance.com/jb_openxml.asp

Jeg har dog ingen erfaringer med performance af denne funktion.

stigc > nop. Transaktionen GARANTERER at alt det du har gjort inde i transaktionen bliver udført eller ikke udført, så hvis du laver f.eks. 3 statements, kan du efterfølgende vælge at COMMITe eller ROLLBACKe den transaktion der er tale om. Dette er ekstra resourcer da serveren så skal holde styr på de ændringer der er foretaget ind til der committes eller bliver lavet rollback, og derfor kan jeg ikke se andet end at det må være langsommere.
Og bare sårn i al almindelighed, så er Stored Procedures hurtigst. Serveren har så nemlig mulighed for at 'smage' på den logik der er i den stored procedure, og derfor udføres de hurtigere end almindelige queries.

Just4Fun> Det er altså ikke rigtigt at transaktioner "bare" giver en garanti for at alle statements bliver udført. Det sikrer nemlig også at optimizeren i SQL Server ved hvad der vil ske gennem hele transaktionen - det giver en forbedring af performance. Bagsiden af medaljen er at du genererer "locks" når tingene foregår i transaktioner... det vil sige at det går ud over den overordnede performance hvis der laves lange transaktioner mens andre processer kører.