Db2 Gleitender Durchschnitt

Dies ist eine Evergreen Joe Celko Frage. Ich ignoriere, welche DBMS-Plattform verwendet wird. Aber auf jeden Fall Joe war in der Lage, mehr als 10 Jahren mit Standard-SQL zu beantworten. Joe Celko SQL Puzzles und Antworten Zitat: Der letzte Update-Versuch deutet darauf hin, dass wir das Prädikat verwenden könnten, um eine Abfrage, die uns einen gleitenden Durchschnitt geben würde: Ist die zusätzliche Spalte oder die Abfrage Ansatz besser Die Abfrage ist technisch besser, weil die UPDATE-Ansatz wird Denormalisierung der Datenbank. Wenn jedoch die historischen Daten, die aufgezeichnet werden, sich nicht ändern und die Berechnung des gleitenden Durchschnitts kostspielig ist, könnten Sie die Verwendung des Spaltenansatzes in Erwägung ziehen. SQL Puzzle-Abfrage: mit allen Mitteln einheitlich. Sie werfen nur auf den entsprechenden Gewichtskorb je nach Entfernung vom aktuellen Zeitpunkt. Zum Beispiel quottake Gewicht1 für Datenpunkte innerhalb von 24 Stunden von aktuellen Datenpunkt Gewicht0,5 für Datenpunkte innerhalb von 48hrsquot. In diesem Fall ist es wichtig, wieviel aufeinander folgende Datenpunkte (wie 6:12 Uhr und 11:48 Uhr) voneinander entfernt sind. Ein Anwendungsfall, den ich mir vorstellen kann, wäre ein Versuch, das Histogramm dort zu glätten, wo Datenpunkte nicht dicht genug sind ndash msciwoj Mai 27 15 at 22:22 Im nicht sicher, dass Ihr erwarteten Ergebnis (Ausgang) zeigt klassische einfache bewegen (rolling) Durchschnitt für 3 Tage. Denn zum Beispiel gibt das erste Dreibettzimmer von Zahlen per Definition: aber man erwartet 4.360 und seine Verwirrung. Trotzdem schlage ich die folgende Lösung vor, die die Fensterfunktion AVG verwendet. Dieser Ansatz ist viel effizienter (klarer und weniger ressourcenintensiv) als SELF-JOIN in anderen Antworten eingeführt (und ich bin überrascht, dass niemand eine bessere Lösung gegeben hat). Sie sehen, dass AVG wird mit Fall verpackt, wenn rownum gt p. days dann zu zwingen, NULL s in ersten Zeilen, wo 3 Tage Moving Average ist sinnlos. Beantwortet Joe Celkos dirty linken äußeren Join-Methode (wie zitiert von Diego Scaravaggi) auf die Frage zu beantworten, wie es gefragt wurde. Generiert die angeforderte Ausgabe: Antwort # 2 am: Januar 16, 2010, um 10:33 Uhr Ihre Antwort 2017 Stack Exchange, IncWeight gleitenden Durchschnitt in T-SQL In einem früheren Beitrag habe ich die Berechnung der gleitenden Durchschnitte in T-SQL gezeigt. Allerdings gibt es einen großen Nachteil mit einfachen gleitenden Durchschnitten. Preisänderungen am Anfang der Periode haben die gleiche Bedeutung wie die jüngsten Preisänderungen. Irgendwie haben Sie gerne die verschiedenen Gewichte zu den Preisänderungen zuweisen, so dass die jüngsten Änderungen das meiste Gewicht bekommen. Dazu kann ein Weighted Moving Average (WMA) berechnet werden. In diesem Blog-Beitrag werde ich zeigen zwei verschiedene Methoden, um WMA zu berechnen, eine, die auf SQL Server 2005 und höher verwendet werden kann, und die andere Version ist für SQL Server-Versionen früher als 2005. Um das relative Gewicht jeder Preisänderung zu berechnen, Müssen die Position jeder Preisänderung relativ zum berechneten Tag kennen. Daher kann eine Fensterfunktion nicht verwendet werden. Es ist nicht möglich, Informationen aus den einzelnen Zeilen im Fenster zu erhalten. Im folgenden Beispiel wird der gewichtete gleitende Durchschnitt für 9 Tage (WMA9) berechnet. Das Beispiel verwendet das TAdb. Ein Skript zur Erstellung von TAdb finden Sie hier. Unabhängig von der SQL Server-Version, für jede Zeile müssen wir auf die 8 vorherigen Zeilen, 9 mit der aktuellen Zeile enthalten. Diese 9 Zeilen sind das Fenster, das unsere Preisänderungen enthält. Jeder Zeile in diesem Fenster wird ein lineares Gewicht zugewiesen, das mit dem gleichen Betrag für jede Zeile bis zur aktuellen Zeile zunimmt. Das Gewicht für jede Zeile wird berechnet, indem die Fensterreihenposition relativ zur aktuellen Zeile verwendet wird. Let8217s sagen, dass wir WMA für die 9-te Zeile berechnen wollen (Zitate von TAdb StockId 1): 1 30,02 30,02 2 30,33 60,66 3 30,33 90,99 4 30,44 121,76 5 30,24 151,20 6 30,27 181,62 7 29,87 209,09 8 30,00 240,00 9 30,02 270,18 Die Summe der obigen ist 1355,52. Dies wird dann durch die Summe der Gewichte dividiert, das heißt 123456789 45. Das WMA9 für Zeile 9 ist 1355,52 45 30,12. Wenn Sie WMA ausser für 9 Tage berechnen möchten, verwenden Sie die folgende T-SQL (erhalten Sie hier die GetNums2-Funktion), um den Divisor für die Periodenlänge (zB 45 für 9 Tage WMA) zu erhalten: Gewichtete Moving Average (WMA) Divisoren Gewichteter gleitender Durchschnitt SQL Server 2005 und höher Diese Version verwendet einen CTE, um die WMA zu berechnen: Ergebnis für 9 Tage Gewichteter gleitender Durchschnitt (WMA9) In den obigen Ergebnissen können Sie sehen, dass das WMA9 für Zeile 9 30,12 ist, wie zuvor berechnet. Weighted Moving Average vor SQL Server 2005 Der einzige Unterschied zwischen der SQL Server 2005-Version und dieser ist die Verwendung eines gemeinsamen Tabellenausdrucks. Die Vor 2005-Version verwendet tatsächliche Tabellen anstelle von CTE8217s: Leistung Wenn Sie einen einfachen gleitenden Durchschnitt berechnen und SQL Server 2012 oder höher verwenden, kann eine riesige Verbesserung in der Leistung gesehen werden, wenn Fensterfunktionen im Vergleich zu den alternativen Metohods verwendet werden, die in älteren Versionen von SQL Server verwendet werden . Berechnungen von gewichteten gleitenden Durchschnitten können jedoch Fensterfunktionen auf dieselbe Weise verwenden. Ein Vergleich zwischen der SQL Server 2005-Version von WMA zeigt eine kleine Verbesserung gegenüber den Versionen, die in älteren Versionen von SQL Server verwendet werden: T-SQL WMA SQL Server 2005 verglichen mit Version 2005. Wegen der teuren Berechnungen in WMA beteiligt, könnte es eine gute Idee, um die Ergebnisse bestehen. WMA werden in der Trendanalyse genauso wie SMA verwendet. WMA hat mehr Gewicht auf die jüngsten Preisänderungen jedoch. Dieser Blog-Beitrag ist Teil einer Serie über technische Analyse, TA, in SQL Server. Siehe die anderen Beiträge hier. Geschrieben von Tomas Lind Tomas Lind - Consulting als SQL Server DBA und Datenbankentwickler bei High Coast Database Solutions AB.