NOSprocket Skrevet 22. november 2007 Del Skrevet 22. november 2007 Vi har en prosedyre som skal kopiere nye rader fra en tabell til en annen tabell i en annen database. Begge databasene kjøres på samme server med SQL 2000, og Windows 2003. Det er to servere i cluster, noe som er årsaken til at triggere ikke blir benyttet, og at det i perioder kommer mellom 15-20 nye rader pr sekund på det mest hektiske. Mitt spørsmål: Holder det å kjøre en spørring som dette? INSERT INTO DBA.dbo.tablename (value1,value2) SELECT value1 value2 FROM DB2.dbo.tablename WHERE status=1 UPDATE DB2.dbo.tablename SET status=2 WHERE status=1 Eller bør vi fortsette å gjøre slik som vi gjør i dag: UPDATE DB2.dbo.tablename SET status=2 INSERT INTO DBA.dbo.tablename (value1,value2) SELECT value1 value2 FROM DB2.dbo.tablename WHERE status=2 UPDATE DB2.dbo.tablename SET status=3 WHERE status=2 Vil vi kunne risikere på første eksempel at rader som ikke blir med på første INSERT kan få status 2? Finnes det andre alternativer som er raskere? Lenke til kommentar
roac Skrevet 22. november 2007 Del Skrevet 22. november 2007 (endret) Her er det ikke bare snakk om hva som er raskest og ikke. For det første, jeg ville klart gått for løsning 1 av disse to, men spørsmålet er jo også om du virkelig har behov for å ha dataene i begge tabellene, eller om du like gjerne kunne referert dem på annet sett. Hvis du har kode som henter dataene direkte så kunne du laget et view (i enterprise edtion sågar et indeksert) som henter data fra den andre databasen. Jeg er sterk motstander av dobbeltlagring av data Raskere kopiering får du ikke Hvis det så viser seg at du MÅ kopiere dataene, så se for all del på begin transaction ... commit/rollback. Kjør oppdateringen i en transasksjon, og sørg for at enten alle tre statements går bra, eller at ingen av dem blir utført. Uforutsette hendelser kan komme, og da er det best å være froberedt Endret 22. november 2007 av roac Lenke til kommentar
NOSprocket Skrevet 22. november 2007 Forfatter Del Skrevet 22. november 2007 (endret) Her er det ikke bare snakk om hva som er raskest og ikke. For det første, jeg ville klart gått for løsning 1 av disse to, men spørsmålet er jo også om du virkelig har behov for å ha dataene i begge tabellene, eller om du like gjerne kunne referert dem på annet sett. Hvis du har kode som henter dataene direkte så kunne du laget et view (i enterprise edtion sågar et indeksert) som henter data fra den andre databasen. Jeg er sterk motstander av dobbeltlagring av data Raskere kopiering får du ikke Hvis det så viser seg at du MÅ kopiere dataene, så se for all del på begin transaction ... commit/rollback. Kjør oppdateringen i en transasksjon, og sørg for at enten alle tre statements går bra, eller at ingen av dem blir utført. Uforutsette hendelser kan komme, og da er det best å være froberedt Støtter fult ut tanken mot dobbeltlagring, men i dette tilfellet er det gjort for å avlaste den ene tabellen slik at håndteringen av data skjer flere steder og deretter fjernes. Skal se litt mer på dette med begin transaction osv. Har "sett dette" et og annet sted, men aldri benyttet dette selv. Om du har en eksempelkode så legg gjerne ved dette. (finner det sikkert selv et sted også, men kan være andre enn meg som har godt av ekstra info Endret 22. november 2007 av NOSprocket Lenke til kommentar
Anbefalte innlegg
Opprett en konto eller logg inn for å kommentere
Du må være et medlem for å kunne skrive en kommentar
Opprett konto
Det er enkelt å melde seg inn for å starte en ny konto!
Start en kontoLogg inn
Har du allerede en konto? Logg inn her.
Logg inn nå