Daten werden aus verschiedenen Gründen erfasst und gespeichert. Unzählige Stunden (und noch mehr Budget), die in das Sammeln, Erfassen, Strukturieren, Validieren und letztendlich Speichern von Daten investiert wurden; Zu sagen, dass es sich um ein wertvolles Gut handelt, ist ein strittiger Punkt. Heutzutage ist es vielleicht sogar unser wertvollstes Gut.
Einige Daten werden ausschließlich als Archiv verwendet. Vielleicht, um Ereignisse aufzuzeichnen oder zu verfolgen, die in der Vergangenheit passiert sind. Aber die andere Seite dieser Medaille ist, dass historische Daten wertvoll sind, um Entscheidungen für die Zukunft und zukünftige Unternehmungen zu treffen.
- An welchem Tag soll unser Sale stattfinden? (Planung zukünftiger Verkäufe basierend auf der bisherigen Leistung.)
- Welcher Verkäufer hat im ersten Quartal am besten abgeschnitten? (Wenn wir zurückblicken, wen können wir für seine Bemühungen belohnen.)
- Welches Restaurant ist Mitte Juli am meisten besucht? (Die Reisesaison steht vor der Tür... An wen können wir unsere Lebensmittel und Waren verkaufen?)
Du bekommst das Bild. Die Verwendung vorhandener Daten ist für jede Organisation von wesentlicher Bedeutung.
Viele Unternehmen erstellen, gründen und stellen Dienste mit Daten bereit. Sie sind darauf angewiesen.
Vor einigen Monaten, je nachdem, wann Sie dies lesen, begann ich ernsthaft zu laufen, um Gewicht zu verlieren, meine Gesundheit in den Griff zu bekommen und ein tägliches Stück Einsamkeit von dieser geschäftigen Welt, in der wir leben, zu suchen. P>
Ich habe eine mobile Schrittzähler-App verwendet, um meine Wanderungen aufzuzeichnen, auch wenn ich bedenke, welche Schuhe ich trage, da ich bei Schuhen sehr wählerisch bin.
Obwohl diese Daten nicht annähernd so wichtig sind wie die in den oben genannten Szenarien, ist es für mich ein Schlüsselelement, etwas zu lernen, etwas zu verwenden, an dem ich interessiert bin, mit dem ich mich identifizieren kann und das ich verstehe.
Fensterfunktionen sind schon seit langem auf meinem Radar, um sie zu erkunden. Also dachte ich mir, in diesem Beitrag ein paar davon auszuprobieren. Nachdem ich kürzlich in MySQL 8 unterstützt wurde (Besuchen Sie diesen Blog von Multiplenines, in dem ich über MySQL 8-Upgrades und neue Ergänzungen geschrieben habe, wo ich sie kurz erwähne), werde ich dieses Ökosystem hier verwenden. Seien Sie gewarnt, ich bin kein Guru für Fensteranalysefunktionen.
Was ist eine MySQL-Fensterfunktion?
Die MySQL-Dokumentation definiert sie wie folgt: "Eine Fensterfunktion führt eine aggregierte Operation an einer Reihe von Abfragezeilen durch. Während jedoch eine aggregierte Operation Abfragezeilen in einer einzigen Ergebniszeile gruppiert, erzeugt eine Fensterfunktion ein Ergebnis für jede Abfragezeile:"
Datensatz und Einrichtung für diesen Beitrag
Die erfassten Daten meiner Spaziergänge speichere ich in dieser Tabelle:
mysql> DESC hiking_stats;
+-----------------+--------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+-----------------+--------------+------+-----+---------+-------+
| day_walked | date | YES | | NULL | |
| burned_calories | decimal(4,1) | YES | | NULL | |
| distance_walked | decimal(4,2) | YES | | NULL | |
| time_walking | time | YES | | NULL | |
| pace | decimal(2,1) | YES | | NULL | |
| shoes_worn | text | YES | | NULL | |
| trail_hiked | text | YES | | NULL | |
+-----------------+--------------+------+-----+---------+-------+
7 rows in set (0.01 sec)
Hier befinden sich Daten aus fast 90 Tagen:
mysql> SELECT COUNT(*) FROM hiking_stats;
+----------+
| COUNT(*) |
+----------+
| 84 |
+----------+
1 row in set (0.00 sec)
Ich gebe zu, ich bin wählerisch in Bezug auf meine Schuhe, also lass uns herausfinden, welches Paar Schuhe ich am liebsten mag:
mysql> SELECT DISTINCT shoes_worn, COUNT(*)
-> FROM hiking_stats
-> GROUP BY shoes_worn;
+---------------------------------------+----------+
| shoes_worn | COUNT(*) |
+---------------------------------------+----------+
| New Balance Trail Runners-All Terrain | 30 |
| Oboz Sawtooth Low | 47 |
| Keen Koven WP(keen-dry) | 6 |
| New Balance 510v2 | 1 |
+---------------------------------------+----------+
4 rows in set (0.00 sec)
Um eine bessere, überschaubare Demonstration auf dem Bildschirm bereitzustellen, beschränke ich den verbleibenden Teil der Abfrageergebnisse auf die Lieblingsschuhe, die ich 47 Mal getragen habe.
Ich habe auch eine trail_hiked-Spalte und da war ich im 'Ultra-Übungsmodus ' Während dieser fast 3 Monate habe ich sogar Kalorien gezählt, während ich den Garten gemäht habe:
mysql> SELECT DISTINCT trail_hiked, COUNT(*)
-> FROM hiking_stats
-> GROUP BY trail_hiked;
+------------------------+----------+
| trail_hiked | COUNT(*) |
+------------------------+----------+
| Yard Mowing | 14 |
| Sandy Trail-Drive | 20 |
| West Boundary | 29 |
| House-Power Line Route | 10 |
| Tree Trail-extended | 11 |
+------------------------+----------+
5 rows in set (0.01 sec)
Um den Datensatz noch weiter einzuschränken, werde ich diese Zeilen jedoch auch herausfiltern:
mysql> SELECT COUNT(*)
-> FROM hiking_stats
-> WHERE shoes_worn = 'Oboz Sawtooth Low'
-> AND
-> trail_hiked <> 'Yard Mowing';
+----------+
| COUNT(*) |
+----------+
| 40 |
+----------+
1 row in set (0.01 sec)
Der Einfachheit und Benutzerfreundlichkeit halber werde ich eine ANSICHT der Spalten erstellen, mit denen ich arbeiten kann:
mysql> CREATE VIEW vw_fav_shoe_stats AS
-> (SELECT day_walked, burned_calories, distance_walked, time_walking, pace, trail_hiked
-> FROM hiking_stats
-> WHERE shoes_worn = 'Oboz Sawtooth Low'
-> AND trail_hiked <> 'Yard Mowing');
Query OK, 0 rows affected (0.19 sec)
Lassen Sie mich mit diesem Datensatz zurück:
mysql> SELECT * FROM vw_fav_shoe_stats;
+------------+-----------------+-----------------+--------------+------+------------------------+
| day_walked | burned_calories | distance_walked | time_walking | pace | trail_hiked |
+------------+-----------------+-----------------+--------------+------+------------------------+
| 2018-06-03 | 389.6 | 4.11 | 01:13:19 | 3.4 | Sandy Trail-Drive |
| 2018-06-04 | 394.6 | 4.26 | 01:14:15 | 3.4 | Sandy Trail-Drive |
| 2018-06-06 | 384.6 | 4.10 | 01:13:14 | 3.4 | Sandy Trail-Drive |
| 2018-06-07 | 382.7 | 4.12 | 01:12:52 | 3.4 | Sandy Trail-Drive |
| 2018-06-17 | 296.3 | 2.82 | 00:55:45 | 3.0 | West Boundary |
| 2018-06-18 | 314.7 | 3.08 | 00:59:13 | 3.1 | West Boundary |
| 2018-06-20 | 338.5 | 3.27 | 01:03:42 | 3.1 | West Boundary |
| 2018-06-21 | 339.5 | 3.40 | 01:03:54 | 3.2 | West Boundary |
| 2018-06-24 | 392.4 | 3.76 | 01:13:51 | 3.1 | House-Power Line Route |
| 2018-06-25 | 362.1 | 3.72 | 01:08:09 | 3.3 | West Boundary |
| 2018-06-26 | 380.5 | 3.94 | 01:11:36 | 3.3 | West Boundary |
| 2018-07-03 | 323.7 | 3.29 | 01:00:55 | 3.2 | West Boundary |
| 2018-07-04 | 342.8 | 3.47 | 01:04:31 | 3.2 | West Boundary |
| 2018-07-06 | 375.7 | 3.80 | 01:10:42 | 3.2 | West Boundary |
| 2018-07-07 | 347.6 | 3.40 | 01:05:25 | 3.1 | Sandy Trail-Drive |
| 2018-07-08 | 351.6 | 3.58 | 01:06:09 | 3.2 | West Boundary |
| 2018-07-09 | 336.0 | 3.28 | 01:03:13 | 3.1 | West Boundary |
| 2018-07-11 | 375.2 | 3.81 | 01:10:37 | 3.2 | West Boundary |
| 2018-07-12 | 325.9 | 3.28 | 01:01:20 | 3.2 | West Boundary |
| 2018-07-15 | 382.9 | 3.91 | 01:12:03 | 3.3 | House-Power Line Route |
| 2018-07-16 | 368.6 | 3.72 | 01:09:22 | 3.2 | West Boundary |
| 2018-07-17 | 339.4 | 3.46 | 01:03:52 | 3.3 | West Boundary |
| 2018-07-18 | 368.1 | 3.72 | 01:08:28 | 3.3 | West Boundary |
| 2018-07-19 | 339.2 | 3.44 | 01:03:06 | 3.3 | West Boundary |
| 2018-07-22 | 378.3 | 3.76 | 01:10:22 | 3.2 | West Boundary |
| 2018-07-23 | 322.9 | 3.28 | 01:00:03 | 3.3 | West Boundary |
| 2018-07-24 | 386.4 | 3.81 | 01:11:53 | 3.2 | West Boundary |
| 2018-07-25 | 379.9 | 3.83 | 01:10:39 | 3.3 | West Boundary |
| 2018-07-27 | 378.3 | 3.73 | 01:10:21 | 3.2 | West Boundary |
| 2018-07-28 | 337.4 | 3.39 | 01:02:45 | 3.2 | Sandy Trail-Drive |
| 2018-07-29 | 348.7 | 3.50 | 01:04:52 | 3.2 | West Boundary |
| 2018-07-30 | 361.6 | 3.69 | 01:07:15 | 3.3 | West Boundary |
| 2018-07-31 | 359.9 | 3.66 | 01:06:57 | 3.3 | West Boundary |
| 2018-08-01 | 336.1 | 3.37 | 01:01:48 | 3.3 | West Boundary |
| 2018-08-03 | 259.9 | 2.57 | 00:47:47 | 3.2 | West Boundary |
| 2018-08-05 | 341.2 | 3.37 | 01:02:44 | 3.2 | West Boundary |
| 2018-08-06 | 357.7 | 3.64 | 01:05:46 | 3.3 | West Boundary |
| 2018-08-17 | 184.2 | 1.89 | 00:39:00 | 2.9 | Tree Trail-extended |
| 2018-08-18 | 242.9 | 2.53 | 00:51:25 | 3.0 | Tree Trail-extended |
| 2018-08-30 | 204.4 | 1.95 | 00:37:35 | 3.1 | House-Power Line Route |
+------------+-----------------+-----------------+--------------+------+------------------------+
40 rows in set (0.00 sec)
Die erste Fensterfunktion, die ich mir ansehen werde, ist ROW_NUMBER().
Angenommen, ich möchte eine Ergebnismenge, die nach der Spalte „burned_calories“ für den Monat „Juli“ geordnet ist.
Natürlich kann ich diese Daten mit dieser Abfrage abrufen:
mysql> SELECT day_walked, burned_calories, trail_hiked
-> FROM vw_fav_shoe_stats
-> WHERE MONTHNAME(day_walked) = 'July'
-> ORDER BY burned_calories DESC;
+------------+-----------------+------------------------+
| day_walked | burned_calories | trail_hiked |
+------------+-----------------+------------------------+
| 2018-07-24 | 386.4 | West Boundary |
| 2018-07-15 | 382.9 | House-Power Line Route |
| 2018-07-25 | 379.9 | West Boundary |
| 2018-07-22 | 378.3 | West Boundary |
| 2018-07-27 | 378.3 | West Boundary |
| 2018-07-06 | 375.7 | West Boundary |
| 2018-07-11 | 375.2 | West Boundary |
| 2018-07-16 | 368.6 | West Boundary |
| 2018-07-18 | 368.1 | West Boundary |
| 2018-07-30 | 361.6 | West Boundary |
| 2018-07-31 | 359.9 | West Boundary |
| 2018-07-08 | 351.6 | West Boundary |
| 2018-07-29 | 348.7 | West Boundary |
| 2018-07-07 | 347.6 | Sandy Trail-Drive |
| 2018-07-04 | 342.8 | West Boundary |
| 2018-07-17 | 339.4 | West Boundary |
| 2018-07-19 | 339.2 | West Boundary |
| 2018-07-28 | 337.4 | Sandy Trail-Drive |
| 2018-07-09 | 336.0 | West Boundary |
| 2018-07-12 | 325.9 | West Boundary |
| 2018-07-03 | 323.7 | West Boundary |
| 2018-07-23 | 322.9 | West Boundary |
+------------+-----------------+------------------------+
22 rows in set (0.01 sec)
Dennoch möchte ich aus irgendeinem Grund (vielleicht aus persönlicher Zufriedenheit) vergeben ein Ranking unter den zurückgegebenen Zeilen, beginnend mit 1, was auf die höchste Zahl an verbrannten_Kalorien hinweist, bis hin zu (n) Zeilen in der Ergebnismenge.
ROW_NUMBER(), kann damit überhaupt kein Problem umgehen:
mysql> SELECT day_walked, burned_calories,
-> ROW_NUMBER() OVER(ORDER BY burned_calories DESC)
-> AS position, trail_hiked
-> FROM vw_fav_shoe_stats
-> WHERE MONTHNAME(day_walked) = 'July';
+------------+-----------------+----------+------------------------+
| day_walked | burned_calories | position | trail_hiked |
+------------+-----------------+----------+------------------------+
| 2018-07-24 | 386.4 | 1 | West Boundary |
| 2018-07-15 | 382.9 | 2 | House-Power Line Route |
| 2018-07-25 | 379.9 | 3 | West Boundary |
| 2018-07-22 | 378.3 | 4 | West Boundary |
| 2018-07-27 | 378.3 | 5 | West Boundary |
| 2018-07-06 | 375.7 | 6 | West Boundary |
| 2018-07-11 | 375.2 | 7 | West Boundary |
| 2018-07-16 | 368.6 | 8 | West Boundary |
| 2018-07-18 | 368.1 | 9 | West Boundary |
| 2018-07-30 | 361.6 | 10 | West Boundary |
| 2018-07-31 | 359.9 | 11 | West Boundary |
| 2018-07-08 | 351.6 | 12 | West Boundary |
| 2018-07-29 | 348.7 | 13 | West Boundary |
| 2018-07-07 | 347.6 | 14 | Sandy Trail-Drive |
| 2018-07-04 | 342.8 | 15 | West Boundary |
| 2018-07-17 | 339.4 | 16 | West Boundary |
| 2018-07-19 | 339.2 | 17 | West Boundary |
| 2018-07-28 | 337.4 | 18 | Sandy Trail-Drive |
| 2018-07-09 | 336.0 | 19 | West Boundary |
| 2018-07-12 | 325.9 | 20 | West Boundary |
| 2018-07-03 | 323.7 | 21 | West Boundary |
| 2018-07-23 | 322.9 | 22 | West Boundary |
+------------+-----------------+----------+------------------------+
22 rows in set (0.00 sec)
Sie können sehen, dass die Zeile mit der Menge an verbrannten_Kalorien von 386,4 Position hat 1, während die Zeile mit dem Wert 322,9 22 hat, was die kleinste (oder niedrigste) Menge unter den zurückgegebenen Zeilen ist.
Ich werde ROW_NUMBER() im weiteren Verlauf für etwas Interessanteres verwenden. Erst als ich davon erfuhr, dass es in diesem Zusammenhang verwendet wird, wurde mir wirklich etwas von seiner wahren Kraft bewusst.
Als nächstes besuchen wir die Fensterfunktion RANK(), um eine andere Art von 'Ranking bereitzustellen “ zwischen den Reihen. Wir werden weiterhin auf den Wert der Spalte „burned_calories“ abzielen. Und während RANK() ROW_NUMBER() insofern ähnlich ist, als sie Zeilen in gewisser Weise einordnen, führt es unter bestimmten Umständen einen subtilen Unterschied ein.
Ich werde die Anzahl der Zeilen als Ganzes noch weiter einschränken, indem ich alle Datensätze filtere, die nicht im Monat „Juli“ liegen, sondern auf einen bestimmten Pfad abzielen:
mysql> SELECT day_walked, burned_calories,
-> RANK() OVER(ORDER BY burned_calories DESC) AS position,
-> trail_hiked
-> FROM vw_fav_shoe_stats
-> WHERE MONTHNAME(day_walked) = 'July'
-> AND trail_hiked = 'West Boundary';
+------------+-----------------+----------+---------------+
| day_walked | burned_calories | position | trail_hiked |
+------------+-----------------+----------+---------------+
| 2018-07-24 | 386.4 | 1 | West Boundary |
| 2018-07-25 | 379.9 | 2 | West Boundary |
| 2018-07-22 | 378.3 | 3 | West Boundary |
| 2018-07-27 | 378.3 | 3 | West Boundary |
| 2018-07-06 | 375.7 | 5 | West Boundary |
| 2018-07-11 | 375.2 | 6 | West Boundary |
| 2018-07-16 | 368.6 | 7 | West Boundary |
| 2018-07-18 | 368.1 | 8 | West Boundary |
| 2018-07-30 | 361.6 | 9 | West Boundary |
| 2018-07-31 | 359.9 | 10 | West Boundary |
| 2018-07-08 | 351.6 | 11 | West Boundary |
| 2018-07-29 | 348.7 | 12 | West Boundary |
| 2018-07-04 | 342.8 | 13 | West Boundary |
| 2018-07-17 | 339.4 | 14 | West Boundary |
| 2018-07-19 | 339.2 | 15 | West Boundary |
| 2018-07-09 | 336.0 | 16 | West Boundary |
| 2018-07-12 | 325.9 | 17 | West Boundary |
| 2018-07-03 | 323.7 | 18 | West Boundary |
| 2018-07-23 | 322.9 | 19 | West Boundary |
+------------+-----------------+----------+---------------+
19 rows in set (0.01 sec)
Fällt Ihnen hier etwas Seltsames auf? Anders als ROW_NUMBER()?
Überprüfen Sie den Positionswert für die Zeilen „2018-07-22“ und „2018-07-27“. Sie sind auf dem 3. Platz unentschieden.
Aus gutem Grund, da der Burned_calorie-Wert von 378,3 in beiden Zeilen vorhanden ist.
Wie würde ROW_NUMBER() sie einstufen?
Finden wir es heraus:
mysql> SELECT day_walked, burned_calories,
-> ROW_NUMBER() OVER(ORDER BY burned_calories DESC) AS position,
-> trail_hiked
-> FROM vw_fav_shoe_stats
-> WHERE MONTHNAME(day_walked) = 'July'
-> AND trail_hiked = 'West Boundary';
+------------+-----------------+----------+---------------+
| day_walked | burned_calories | position | trail_hiked |
+------------+-----------------+----------+---------------+
| 2018-07-24 | 386.4 | 1 | West Boundary |
| 2018-07-25 | 379.9 | 2 | West Boundary |
| 2018-07-22 | 378.3 | 3 | West Boundary |
| 2018-07-27 | 378.3 | 4 | West Boundary |
| 2018-07-06 | 375.7 | 5 | West Boundary |
| 2018-07-11 | 375.2 | 6 | West Boundary |
| 2018-07-16 | 368.6 | 7 | West Boundary |
| 2018-07-18 | 368.1 | 8 | West Boundary |
| 2018-07-30 | 361.6 | 9 | West Boundary |
| 2018-07-31 | 359.9 | 10 | West Boundary |
| 2018-07-08 | 351.6 | 11 | West Boundary |
| 2018-07-29 | 348.7 | 12 | West Boundary |
| 2018-07-04 | 342.8 | 13 | West Boundary |
| 2018-07-17 | 339.4 | 14 | West Boundary |
| 2018-07-19 | 339.2 | 15 | West Boundary |
| 2018-07-09 | 336.0 | 16 | West Boundary |
| 2018-07-12 | 325.9 | 17 | West Boundary |
| 2018-07-03 | 323.7 | 18 | West Boundary |
| 2018-07-23 | 322.9 | 19 | West Boundary |
+------------+-----------------+----------+---------------+
19 rows in set (0.06 sec)
Hmm...
Diesmal keine Unentschieden in der Positionsspaltennummerierung.
Aber wer hat Vorrang?
Meines Wissens müssen Sie für eine vorhersagbare Reihenfolge wahrscheinlich durch andere zusätzliche Mittel innerhalb der Abfrage bestimmen (z. B. in diesem Fall die Spalte time_walking?).
Aber wir sind noch nicht fertig mit den Ranking-Optionen. Hier ist DENSE_RANK():
mysql> SELECT day_walked, burned_calories,
-> DENSE_RANK() OVER(ORDER BY burned_calories DESC) AS position,
-> trail_hiked
-> FROM vw_fav_shoe_stats
-> WHERE MONTHNAME(day_walked) = 'July'
-> AND trail_hiked = 'West Boundary';
+------------+-----------------+----------+---------------+
| day_walked | burned_calories | position | trail_hiked |
+------------+-----------------+----------+---------------+
| 2018-07-24 | 386.4 | 1 | West Boundary |
| 2018-07-25 | 379.9 | 2 | West Boundary |
| 2018-07-22 | 378.3 | 3 | West Boundary |
| 2018-07-27 | 378.3 | 3 | West Boundary |
| 2018-07-06 | 375.7 | 4 | West Boundary |
| 2018-07-11 | 375.2 | 5 | West Boundary |
| 2018-07-16 | 368.6 | 6 | West Boundary |
| 2018-07-18 | 368.1 | 7 | West Boundary |
| 2018-07-30 | 361.6 | 8 | West Boundary |
| 2018-07-31 | 359.9 | 9 | West Boundary |
| 2018-07-08 | 351.6 | 10 | West Boundary |
| 2018-07-29 | 348.7 | 11 | West Boundary |
| 2018-07-04 | 342.8 | 12 | West Boundary |
| 2018-07-17 | 339.4 | 13 | West Boundary |
| 2018-07-19 | 339.2 | 14 | West Boundary |
| 2018-07-09 | 336.0 | 15 | West Boundary |
| 2018-07-12 | 325.9 | 16 | West Boundary |
| 2018-07-03 | 323.7 | 17 | West Boundary |
| 2018-07-23 | 322.9 | 18 | West Boundary |
+------------+-----------------+----------+---------------+
19 rows in set (0.00 sec)
Das Unentschieden bleibt, aber die Nummerierung unterscheidet sich dahingehend, wo Zeilen gezählt werden , weiter durch die verbleibenden Ergebnisse.
Wo RANK() die Zählung mit 5 nach den Unentschieden begann, setzt DENSE_RANK() bei der nächsten Zahl fort, die in diesem Fall 4 ist, da das Unentschieden in Zeile 3 stattfand.
Ich bin der Erste, der zugibt, dass diese verschiedenen Reihenrangordnungsmuster ziemlich interessant sind, aber wie können Sie sie für eine aussagekräftige Ergebnismenge verwenden?
ClusterControlEine Konsole für Ihre gesamte DatenbankinfrastrukturErfahren Sie, was es sonst noch Neues in ClusterControl gibt. Installieren Sie ClusterControl KOSTENLOSEin Bonusgedanke
Ich muss Ehre geben, wem Ehre gebührt. Ich habe so viel über Fensterfunktionen aus einer wunderbaren Serie auf YouTube gelernt und insbesondere ein Video hat mich zu diesem nächsten Beispiel inspiriert. Bitte denken Sie daran, obwohl die Beispiele in dieser Reihe mit einer Nicht-Open-Source-Datenbank demonstriert werden System (Werfen Sie mir nicht die digitalen faulen Früchte und Gemüse nach), gibt es insgesamt eine Menge aus den Videos zu lernen.
Ich sehe ein Muster in den meisten Abfrageergebnissen, die ich untersuchen möchte. Ich werde nicht nach Monat oder Spur filtern.
Was ich wissen möchte, sind die aufeinanderfolgenden Tage, an denen ich mehr als 350 Kalorien verbrannt habe. Besser noch, Gruppen von damals.
Hier ist die Basisabfrage, mit der ich beginne und auf der ich aufbaue:
mysql> SELECT day_walked, burned_calories,
-> ROW_NUMBER() OVER(ORDER BY day_walked ASC) AS positional_bound,
-> trail_hiked
-> FROM vw_fav_shoe_stats
-> WHERE burned_calories > 350;
+------------+-----------------+------------------+------------------------+
| day_walked | burned_calories | positional_bound | trail_hiked |
+------------+-----------------+------------------+------------------------+
| 2018-06-03 | 389.6 | 1 | Sandy Trail-Drive |
| 2018-06-04 | 394.6 | 2 | Sandy Trail-Drive |
| 2018-06-06 | 384.6 | 3 | Sandy Trail-Drive |
| 2018-06-07 | 382.7 | 4 | Sandy Trail-Drive |
| 2018-06-24 | 392.4 | 5 | House-Power Line Route |
| 2018-06-25 | 362.1 | 6 | West Boundary |
| 2018-06-26 | 380.5 | 7 | West Boundary |
| 2018-07-06 | 375.7 | 8 | West Boundary |
| 2018-07-08 | 351.6 | 9 | West Boundary |
| 2018-07-11 | 375.2 | 10 | West Boundary |
| 2018-07-15 | 382.9 | 11 | House-Power Line Route |
| 2018-07-16 | 368.6 | 12 | West Boundary |
| 2018-07-18 | 368.1 | 13 | West Boundary |
| 2018-07-22 | 378.3 | 14 | West Boundary |
| 2018-07-24 | 386.4 | 15 | West Boundary |
| 2018-07-25 | 379.9 | 16 | West Boundary |
| 2018-07-27 | 378.3 | 17 | West Boundary |
| 2018-07-30 | 361.6 | 18 | West Boundary |
| 2018-07-31 | 359.9 | 19 | West Boundary |
| 2018-08-06 | 357.7 | 20 | West Boundary |
+------------+-----------------+------------------+------------------------+
20 rows in set (0.00 sec)
Wir haben ROW_NUMBER() bereits gesehen, aber jetzt kommt es wirklich ins Spiel.
Damit dies funktioniert (zumindest in MySQL), musste ich die Funktion DATE_SUB() verwenden, da wir mit dieser Technik im Wesentlichen eine Zahl subtrahieren - den von ROW_NUMBER() bereitgestellten Wert von der date_walked-Datumsspalte derselben Zeile, die in wiederum, liefert selbst ein Datum über die Berechnung:
mysql> SELECT day_walked AS day_of_walk,
-> DATE_SUB(day_walked, INTERVAL ROW_NUMBER() OVER(ORDER BY day_walked ASC) DAY) AS positional_bound,
-> burned_calories,
-> trail_hiked
-> FROM vw_fav_shoe_stats
-> WHERE burned_calories > 350;
+-------------+------------------+-----------------+------------------------+
| day_of_walk | positional_bound | burned_calories | trail_hiked |
+-------------+------------------+-----------------+------------------------+
| 2018-06-03 | 2018-06-02 | 389.6 | Sandy Trail-Drive |
| 2018-06-04 | 2018-06-02 | 394.6 | Sandy Trail-Drive |
| 2018-06-06 | 2018-06-03 | 384.6 | Sandy Trail-Drive |
| 2018-06-07 | 2018-06-03 | 382.7 | Sandy Trail-Drive |
| 2018-06-24 | 2018-06-19 | 392.4 | House-Power Line Route |
| 2018-06-25 | 2018-06-19 | 362.1 | West Boundary |
| 2018-06-26 | 2018-06-19 | 380.5 | West Boundary |
| 2018-07-06 | 2018-06-28 | 375.7 | West Boundary |
| 2018-07-08 | 2018-06-29 | 351.6 | West Boundary |
| 2018-07-11 | 2018-07-01 | 375.2 | West Boundary |
| 2018-07-15 | 2018-07-04 | 382.9 | House-Power Line Route |
| 2018-07-16 | 2018-07-04 | 368.6 | West Boundary |
| 2018-07-18 | 2018-07-05 | 368.1 | West Boundary |
| 2018-07-22 | 2018-07-08 | 378.3 | West Boundary |
| 2018-07-24 | 2018-07-09 | 386.4 | West Boundary |
| 2018-07-25 | 2018-07-09 | 379.9 | West Boundary |
| 2018-07-27 | 2018-07-10 | 378.3 | West Boundary |
| 2018-07-30 | 2018-07-12 | 361.6 | West Boundary |
| 2018-07-31 | 2018-07-12 | 359.9 | West Boundary |
| 2018-08-06 | 2018-07-17 | 357.7 | West Boundary |
+-------------+------------------+-----------------+------------------------+
20 rows in set (0.00 sec)
Ohne DATE_SUB() landen Sie jedoch bei diesem (oder zumindest bei mir):
mysql> SELECT day_walked AS day_of_walk,
-> day_walked - ROW_NUMBER() OVER(ORDER BY day_walked ASC) AS positional_bound,
-> burned_calories,
-> trail_hiked
-> FROM vw_fav_shoe_stats
-> WHERE burned_calories > 350;
+-------------+------------------+-----------------+------------------------+
| day_of_walk | positional_bound | burned_calories | trail_hiked |
+-------------+------------------+-----------------+------------------------+
| 2018-06-03 | 20180602 | 389.6 | Sandy Trail-Drive |
| 2018-06-04 | 20180602 | 394.6 | Sandy Trail-Drive |
| 2018-06-06 | 20180603 | 384.6 | Sandy Trail-Drive |
| 2018-06-07 | 20180603 | 382.7 | Sandy Trail-Drive |
| 2018-06-24 | 20180619 | 392.4 | House-Power Line Route |
| 2018-06-25 | 20180619 | 362.1 | West Boundary |
| 2018-06-26 | 20180619 | 380.5 | West Boundary |
| 2018-07-06 | 20180698 | 375.7 | West Boundary |
| 2018-07-08 | 20180699 | 351.6 | West Boundary |
| 2018-07-11 | 20180701 | 375.2 | West Boundary |
| 2018-07-15 | 20180704 | 382.9 | House-Power Line Route |
| 2018-07-16 | 20180704 | 368.6 | West Boundary |
| 2018-07-18 | 20180705 | 368.1 | West Boundary |
| 2018-07-22 | 20180708 | 378.3 | West Boundary |
| 2018-07-24 | 20180709 | 386.4 | West Boundary |
| 2018-07-25 | 20180709 | 379.9 | West Boundary |
| 2018-07-27 | 20180710 | 378.3 | West Boundary |
| 2018-07-30 | 20180712 | 361.6 | West Boundary |
| 2018-07-31 | 20180712 | 359.9 | West Boundary |
| 2018-08-06 | 20180786 | 357.7 | West Boundary |
+-------------+------------------+-----------------+------------------------+
20 rows in set (0.04 sec)
Hey, das sieht gar nicht so schlecht aus.
Was gibt?
Eh, die Zeile mit einem positional_bound-Wert von '20180698'...
Warten Sie eine Minute, dies soll einen Datumswert berechnen, indem die Zahl, die ROW_NUMBER() von der Spalte day_of_walk liefert, subtrahiert wird.
Richtig.
Ich weiß nicht wie es euch geht, aber mir ist kein Monat mit 98 Tagen bekannt!
Aber wenn es einen gibt, bringen Sie die zusätzlichen Gehaltsschecks!
Spaß beiseite, das war offensichtlich falsch und hat mich dazu veranlasst, (irgendwann) DATE_SUB() zu verwenden, das eine korrekte Ergebnismenge liefert und mir dann erlaubt, diese Abfrage auszuführen:
mysql> SELECT MIN(t.day_of_walk),
-> MAX(t.day_of_walk),
-> COUNT(*) AS num_of_hikes
-> FROM (SELECT day_walked AS day_of_walk,
-> DATE_SUB(day_walked, INTERVAL ROW_NUMBER() OVER(ORDER BY day_walked ASC) DAY) AS positional_bound
-> FROM vw_fav_shoe_stats
-> WHERE burned_calories > 350) AS t
-> GROUP BY t.positional_bound
-> ORDER BY 1;
+--------------------+--------------------+--------------+
| MIN(t.day_of_walk) | MAX(t.day_of_walk) | num_of_hikes |
+--------------------+--------------------+--------------+
| 2018-06-03 | 2018-06-04 | 2 |
| 2018-06-06 | 2018-06-07 | 2 |
| 2018-06-24 | 2018-06-26 | 3 |
| 2018-07-06 | 2018-07-06 | 1 |
| 2018-07-08 | 2018-07-08 | 1 |
| 2018-07-11 | 2018-07-11 | 1 |
| 2018-07-15 | 2018-07-16 | 2 |
| 2018-07-18 | 2018-07-18 | 1 |
| 2018-07-22 | 2018-07-22 | 1 |
| 2018-07-24 | 2018-07-25 | 2 |
| 2018-07-27 | 2018-07-27 | 1 |
| 2018-07-30 | 2018-07-31 | 2 |
| 2018-08-06 | 2018-08-06 | 1 |
+--------------------+--------------------+--------------+
13 rows in set (0.12 sec)
Zugehörige Ressourcen ClusterControl für MySQL MySQL im Jahr 2018:Was ist in 8.0 enthalten und andere Beobachtungen MySQL-Leistungsbenchmarking:MySQL 5.7 vs. MySQL 8.0 Im Grunde habe ich verpackt die von dieser analytischen Abfrage bereitgestellten Ergebnisse in Form einer abgeleiteten Tabelle und abgefragt nach:einem Start- und Enddatum, einer Anzahl von dem, was ich als num_of_hikes bezeichnet habe, dann gruppiert in der Positional_bound-Spalte, wodurch letztendlich Gruppen von Gruppen bereitgestellt werden aufeinanderfolgende Tage, an denen ich mehr als 350 Kalorien verbrannt habe.
Sie können im Datumsbereich von 24.06.2018 bis 26.06.2018 sehen, was dazu führte, dass 3 aufeinanderfolgende Tage das Kriterium für den Kalorienverbrauch von 350 in der WHERE-Klausel erfüllten.
Nicht schlecht, wenn ich das nicht sagen will, aber auf jeden Fall eine Platte, die ich ausprobieren und am besten machen möchte!
Schlussfolgerung
Fensterfunktionen sind eine Welt und eine Liga für sich. Ich habe noch nicht einmal an der Oberfläche gekratzt, da ich nur 3 davon in einem 'High-Level behandelt habe ' einleitender und vielleicht trivialer Sinn. Hoffentlich stellen Sie jedoch durch diesen Beitrag fest, dass Sie mit einem 'nötigen Minimum nach recht interessanten und potenziell aufschlussreichen Daten suchen können ' verwenden.
Danke fürs Lesen.