Jeg har en tabel i en MSSQL 2005-server hvor jeg gerne løbende og automatisk vil opdatere nogle felter med aggregerede værdier fra en korresponderende anden tabel.
Helt konkret har jeg en tabel med salgsmuligheder. Til hver salgsmulighed hører så et antal individuelle salg, og jeg vil så gerne opdatere et felt i salgsmulighedstabellen med det sammenlagte forventede salg pr salgsmulighed (givet ved summen af hvert undersalg ganget med den forventede sandsynlighed).
Denne select query giver mig det ønskede resultat i query analyzer:
SELECT opmgr.opid, dt1.forvsalg FROM salgsmuligheder INNER JOIN (SELECT loprecid AS noegle, SUM(number1*duration/100) AS forvsalg FROM salgstabel WHERE rectype ='S' GROUP BY loprecid) AS dt1 ON opmgr.opid=dt1.noegle WHERE opmgr.rectype ='O'
Men hvordan får jeg sat det ind i en stored procedure eller lign. der løbende kan opdatere kolonnen i salgsmulighedslisten?
Tak men hvorfor det? I det her tilfælde er det nødvendigt at opdatere felter i databasen for at de kan blive vist korrekt - det er ikke et performanceproblem, men skyldes begrænsninger på den applikation der kører oven på databasen - der er netop sat specielle felter op i den pågældende tabel til at indeholde brugerdefineret data - det er dem jeg gerne vil udfylde med det beregnede data.
Det ser meget fornuftigt ud, men når nu jeg gerne vil bruge værdier fra salgsmulighedstabellen, skal jeg så ikke henføre til dem snarere end at bruge @opid og @rectype f.eks.?
Funktioner har ikke kendskab til rækken, derfor er parametrer nødvendige. Funktionen skal vide hvilke opid det drejer sig om. Rectype er lavet med en if-sætning fordi den åbenbart er begrænset af selve tabellens indhold. Dvs. der hvor rectype <> 'O' vil der stå NULL i feltet.
Hvis den computed column skal laves på en anden tabel, jamen så er det jo bare at gøre det :)
Tak for hjælpen - det kører nu - jeg lavede det som en stored procedure som jeg sætter til at køre via SQL agenten på serveren, så det løbende opdaterer.
Den ser sådan her ud, hvis nogen skulle være interesseret:
update opmgr
set forecast = (select sum(salgstabel.number1*salgstabel.duration/100) from salgstabel where salgstabel.rectype='S' and salgstabel.loprecid=opmgr.opid) from opmgr inner join salgstabel on salgstabel.loprecid=opmgr.opid where opmgr.rectype='O',
Nu kender jeg ikke til datamængderne, men en god regel er altid at undgå sådanne schedulerede jobs - det skaber mange afhængigheder. Det er klart hvis vi taler mange millioner af rækker og komplicerede beregninger at man planlægger sin update, men i bund og grund kan man komme langt med enten computed columns eller som arne_v nævnte.. at klare det i business laget.
Tak for inputs - hvad mener du præcis med 'afhængigheder'? Altså at man pludselig bliver afhængig af at SQL-agenten ikke går i stå osv.?
Synes godt om
Ny brugerNybegynder
Din løsning...
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.
