webForumDet fria alternativet

Optimering på INSERT?

7 svar · 188 visningar · startad av lolukokasos

lolukokasosMedlem sedan mars 2001196 inlägg
#1

Följande sats används idag och fungerar bra men problemet är att jag antagligen kommer få ökade datamängder i min select-sats. Efter ett enkelt test såg jag att om jag hade ungefär 1000 poster (kan nog tänkas bli en normal mängd data) så tog processen ungefär 10 sek (SQL-server). Detta kommer aldrig användarna att godkänna. Finns det nån optimering man kan göra? Eller kanske rent av nån annan lösning.

insert into anst(fnamn,enamn,email,regdate,proj_id)
select fnamn, enamn, 'KK ' + email email, convert(char,getdate(),101) ,53
from anst

Frågan är kanske av akademisk karaktär men snart så måste jag nog göra nåt åt saken.

spangoMedlem sedan juni 20006 147 inlägg
#2

Eh... det där ser konstigt ut (eller är det jag som är ringrostig?). Nu kopierar du ju i princip hela tabellen anst tillbaka till sig själv.... är det verkligen så det ska vara? Att skyffla 1000 poster fram och tillbaka innebär trots allt en hel del arbete.

F.ö. kan prestandan ökas lite om du inte har så många index i tabellen (dock inte så mycket, har jag hört) men då kan sökprestandan försämras.

------------------
You can't be young forever, but you can be immature indefinitely.

lolukokasosMedlem sedan mars 2001196 inlägg
#3

Du har helt rätt Spango, satsen är lite konstig. Fast meningen är att kopiera alla poster (ev. med villkor) och sedan bara ändra en nyckelpost (i detta fall proj_id) med en variabel. Tanken är att använda de kopierade posterna i en simulering (som kan pågå under en längre tid). Om man sedan bestämmer sig för att godkänna den simuleringen man har jobbat med så tar man bort de gamla värdena alternativt gör simuleringen till skarp version. Gjorde den förklaringen satsen mer förståelig?

Tackar för tipset! Jag tar gärna emot fler tips.

LarsGMedlem sedan dec. 200012 465 inlägg
#4

Hur ser tabellen anst ut i övrigt? Har du någon identity kolumn eller constraints?

Kan du inte lägga in datat i en annan tabell?

Jag tycker att 10 sekunder låter väldigt lång tid. Jag testade (med en annan dbms) och det tog 0.6 sekunder att kopiera 1000 rader (och två index på tabellen) med en insert ... select

(2 år gammal pc).

------------------
essentitia preter non sans multiplicandum

lolukokasosMedlem sedan mars 2001196 inlägg
#5

Tabellen är ännu endast under test, därför är den inte "färdig" (mao påverkningsbar). I den nuvarande tabellen finns en identity-kolumn men inga constraints.
Poängen är att ha alla data i samma tabell. Skulle det vara effektivare att putta in datan i en annan tabell?
Vad använde du för dbms (LarsG) för att nå det resultatet? Har datorns prestanda mycket med det här att göra (jag har också en två gammal pc)?

LarsGMedlem sedan dec. 200012 465 inlägg
#6

Tanken med att ha en annan tabell var mer att då skulle man kunna ha den utan constraint och identitykolumner.

Identitykolumner tar ju lite resurser att hantera och om man skall flytta till en annan tabell och vill ha unika nummer så finns det en funktion som heter identity().

Måste den här kopieringen ske omedelbart? Du nämnde något om en simulering som skulle pågå under en längre tid och kan du inte lägga kopieringen där?

(Databashanteraren heter Mimer.)

------------------
essentitia preter non sans multiplicandum

lolukokasosMedlem sedan mars 2001196 inlägg
#7

Tanken med simulering är att man vid ett givet tillfälle säger: ok, nu vill jag skapa/göra en simulering (av tex. ett projekt). Därefter håller man på att stoppa in resp. ta bort värden och ser hur det ser ut. När man väl bestämt sig så tar man bort eller låter simuleringen bli det rådande i systemet.

Det är alltså vid skapandet av simuleringen som det kan tänkas finnas 1000 poster (kan säkert bli fler också) som ska kopieras fast med ett par förändringar i några kolumner.

Ok, det verkar som att någon stor optimering inte kan göras på ovan nämnda kod, eller?

LarsGMedlem sedan dec. 200012 465 inlägg
#8

Nej, insert-frågan är nog inte så mycket att göra åt.

------------------
essentitia preter non sans multiplicandum

Genererad på 377 ms · cache AV · v20260730165559-full.f96bc7eb