Sql server glidande medelvärde funktion

Flytta genomsnittet i T-SQL En vanlig beräkning i trendanalys är det rörliga (eller rullande) genomsnittet. Ett glidande medelvärde är medelvärdet av t ex de senaste 10 raderna. Det rörliga genomsnittet visar en mer jämn kurva än de faktiska värdena, mer med en längre period för glidande medelvärde, vilket gör det till ett bra verktyg för trendanalys. Detta blogginlägg visar hur man beräknar glidande medelvärde i T-SQL. Olika metoder kommer att användas beroende på versionen av SQL Server. Diagrammet nedan visar utjämningseffekten (röd linje) med ett 200 dagars glidande medelvärde. Aktiekurserna är den blå linjen. Den långsiktiga trenden är tydligt synlig. T-SQL Moving Avergage 200 dagar Demonstrationen nedan kräver TAdb-databasen som kan skapas med manuset som finns här. I det kommande exemplet kommer vi att beräkna ett glidande medelvärde under de senaste 20 dagarna. Beroende på versionen av SQL Server kommer det att finnas en annan metod för att göra beräkningen. Och som vi ser senare har de nyare versionerna av SQL Server funktioner som möjliggör en mycket effektivare beräkning. SQL Server 2012 och senare Flyttande medelvärde Denna version använder sig av en samlad fönsterfunktion. Vad som är nytt i SQL 2012 är möjligheten att begränsa storleken på fönstret genom att ange hur många rader som föregår fönstret ska innehålla: Rader som är föregående är 19, eftersom vi också kommer att inkludera den aktuella raden i beräkningen. Som du kan se är beräkningen av glidande medelvärde i SQL Server 2012 ganska enkelt. Figuren nedan visar fönsterprincipen. Nuvarande rad är markerad med gul. Fönstret är markerat med en blå bakgrund. Det rörliga genomsnittet är helt enkelt genomsnittet av QuoteClose i de blå linjerna: T-SQL Flyttande medelfönster. Resultaten av beräkningarna i äldre versioner av SQL Server är desamma, så de kommer inte att visas igen. SQL Server 2005 8211 2008R2 Flyttande medelvärde Denna version använder sig av ett gemensamt tabelluttryck. CTE är självhänvisat för att få de senaste 20 raderna för varje rad: Flyttande medelvärde före SQL Server 2005 Pre 2005-versionen använder en vänster yttre anslutning till samma tabell för att få de senaste 20 raderna. Det yttre bordet kan sägas innehålla det fönster som vi vill beräkna ett genomsnitt på: Prestationsjämförelse Om vi ​​kör de tre olika metoderna samtidigt och kontrollera den resulterande exekveringsplanen, är det en dramatisk skillnad i prestanda mellan metoderna: Jämförelse av tre olika metoder för att beräkna glidande medelvärde Som du kan se, förbättrar fönsterfunktionsförbättringarna i SQL 2012 en stor skillnad i prestanda. Som nämnts i början av detta inlägg används rörliga medelvärden som ett verktyg för att illustrera trender. Ett gemensamt tillvägagångssätt är att kombinera rörliga medelvärden av olika längder, för att kunna se förändringar på respektive kort, medellång och lång sikt. Av särskilt intresse är korsningen av trendlinjer. Till exempel när den korta trenden rör sig över den långa eller medellånga trenden kan detta tolkas som en köpsignal i teknisk analys. Och när den korta trenden rör sig under en längre trendlinje kan detta tolkas som en försäljningssignal. Diagrammet nedan visar Citat, Ma20, Ma50 och Ma200. T-SQL Ma20, Ma50, Ma200 köp och sälj signaler. Detta blogginlägg är en del av en serie om teknisk analys, TA, i SQL Server. Se andra inlägg här. Upplagt av Tomas Lind Jag arbetar med SQL Server 2008 R2, försöker beräkna ett glidande medelvärde. För varje post enligt min uppfattning vill jag samla värdena för de 250 tidigare posterna och beräkna sedan genomsnittet för det här urvalet. Mina synkolumner är följande: TransaktionsID är unik. För varje TransaktionsID. Jag skulle vilja beräkna medelvärdet för kolumnvärde, över tidigare 250 poster. Så för TransactionID 300, samla alla värden från tidigare 250 rader (vy sorteras nedåt med TransactionID) och sedan i kolumnen MovAvg skriv resultatet av genomsnittet av dessa värden. Jag letar efter att samla in data inom en rad poster. frågade 28 okt 14 kl 20:58 Detta är en Evergreen Joe Celko fråga. Jag ignorerar vilken DBMS-plattform som används. Men i alla fall kunde Joe svara mer än 10 år sedan med standard SQL. Joe Celko SQL Pussel och svar citation: Det senaste uppdateringsförsöket antyder att vi skulle kunna använda predikatet för att konstruera en fråga som skulle ge oss ett glidande medelvärde: Är den extra kolumnen eller frågeställningen bättre Frågan är tekniskt bättre eftersom UPDATE-metoden kommer att denormalisera databasen. Om de historiska data som registreras inte kommer att förändras och beräkningen är det rörliga genomsnittet är dyrt, kan du överväga att använda kolumninriktningen. SQL Pusselfråga: för all del enhetlig. Du kastar bara till lämplig vikthink beroende på avståndet från aktuell tidpunkt. Till exempel kvittot vikt1 för datapoäng inom 24 timmar från nuvarande datapoint weight0.5 för datapoäng inom 48hrsquot. I det fallet spelar det roll hur mycket efterföljande datapoäng (som 6:12 och 11:48) är avlägsna från varandra. Ett användningsfall som jag kan tänka på skulle vara ett försök att släta histogramet där datapunkter inte är täta nog. Ndash msciwoj 27 maj 15 på 22:22 Jag är inte säker på att ditt förväntade resultat (output) visar klassiskt enkelt rörligt (rullande) medelvärde i 3 dagar. Eftersom exempelvis den första trippeln av siffror per definition ger: men du förväntar dig 4,360 och det är förvirrande. Ändå föreslår jag följande lösning, som använder fönsterfunktion AVG. Detta tillvägagångssätt är mycket effektivare (klart och mindre resursintensivt) än SELF-JOIN infört i andra svar (och jag är förvånad över att ingen har givit en bättre lösning). Du ser att AVG är förpackad med fall då rownum gt pays sedan för att tvinga NULL s i första raden, där 3 dagars rörande medelvärde är meningslöst. svarade 23 februari 16 kl 13:12 Vi kan använda Joe Celkos smutsiga vänster yttre anslutningsmetod (som citerad ovan av Diego Scaravaggi) för att svara på frågan som den ställdes. Genererar den begärda utgåvan: svarat jan 9 16 kl 0:33 Ditt svar 2017 Stack Exchange, Inc