Dữ liệu được thu thập và lưu trữ vì nhiều lý do. Số giờ vượt quá số giờ (và thậm chí nhiều ngân sách hơn) được đầu tư vào việc thu thập, nhập, cấu trúc, xác thực và cuối cùng là lưu trữ dữ liệu; để nói rằng nó là một tài sản có giá trị là thúc đẩy một điểm tranh luận về nhà. Trong thời đại ngày nay, trên thực tế, nó có thể là mặt hàng quý giá nhất của chúng ta.
Một số dữ liệu được sử dụng nghiêm ngặt như một kho lưu trữ. Có lẽ để ghi lại hoặc theo dõi các sự kiện đã xảy ra trong quá khứ. Nhưng mặt khác của xu hướng đó là dữ liệu lịch sử có giá trị trong việc đưa ra các quyết định cơ bản cho tương lai và những nỗ lực trong tương lai.
- Giảm giá của chúng tôi vào ngày nào? (Lập kế hoạch bán hàng trong tương lai dựa trên cách chúng tôi đã làm trong quá khứ.)
- Nhân viên bán hàng nào hoạt động tốt nhất trong quý một? (Nhìn lại, chúng ta có thể thưởng cho ai cho những nỗ lực của họ.)
- Nhà hàng nào được lui tới nhiều nhất vào giữa tháng 7? (Mùa du lịch đang đến với chúng ta ... Chúng ta có thể bán thực phẩm và hàng hóa cho ai?)
Bạn nhận được hình ảnh. Sử dụng dữ liệu có trong tay là điều không thể thiếu đối với bất kỳ tổ chức nào.
Nhiều công ty xây dựng, cơ sở và cung cấp dịch vụ với dữ liệu. Họ phụ thuộc vào nó.
Vài tháng trở lại đây, tùy thuộc vào thời điểm bạn đọc nó, tôi bắt đầu đi bộ để tập thể dục, một cách nghiêm túc, để giảm cân, kiểm soát sức khỏe của mình và tìm kiếm một chút cô đơn hàng ngày khỏi thế giới bận rộn mà chúng ta đang sống này.
Tôi đã sử dụng ứng dụng máy đếm bước đi trên thiết bị di động để theo dõi quá trình đi bộ của mình, thậm chí xem xét loại giày nào tôi đã đi, vì tôi có xu hướng cực kỳ kén chọn giày dép.
Mặc dù dữ liệu này gần như không quan trọng bằng dữ liệu được đề cập trong các tình huống ở trên, nhưng đối với tôi, yếu tố quan trọng trong việc học bất cứ thứ gì, là sử dụng thứ mà tôi quan tâm, có thể liên quan và hiểu được.
Các Chức năng Cửa sổ đã nằm trong tầm ngắm của tôi từ lâu. Vì vậy, tôi nghĩ hãy thử sức mình với một vài trong số chúng trong bài đăng này. Gần đây đã được hỗ trợ trong MySQL 8 (Truy cập blog này của Somenines, tôi đã viết về các bản nâng cấp MySQL 8 và các bổ sung mới mà tôi đề cập ngắn gọn) hệ sinh thái đó là hệ sinh thái mà tôi sẽ sử dụng ở đây. Hãy cảnh báo trước, tôi không phải là chuyên gia về chức năng phân tích cửa sổ.
Hàm cửa sổ MySQL là gì?
Tài liệu MySQL định nghĩa chúng như sau: "Một hàm cửa sổ thực hiện một hoạt động giống như tổng hợp trên một tập hợp các hàng truy vấn. Tuy nhiên, trong khi một hoạt động tổng hợp nhóm các hàng truy vấn thành một hàng kết quả duy nhất, thì một hàm cửa sổ tạo ra một kết quả cho mỗi hàng truy vấn:"
Tập dữ liệu và thiết lập cho bài đăng này
Tôi lưu trữ dữ liệu thu được từ các lần đi bộ của mình trong bảng này:
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)
Có gần 90 ngày giá trị dữ liệu ở đây:
mysql> SELECT COUNT(*) FROM hiking_stats;
+----------+
| COUNT(*) |
+----------+
| 84 |
+----------+
1 row in set (0.00 sec)
Tôi thừa nhận rằng, tôi rất sành sỏi về giày dép của mình, vì vậy hãy xác định xem tôi yêu thích đôi giày nào nhất:
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)
Để cung cấp phần trình diễn trên màn hình tốt hơn, có thể quản lý được, tôi sẽ giới hạn phần kết quả truy vấn còn lại chỉ là những kết quả của đôi giày yêu thích mà tôi đã mang 47 lần.
Tôi cũng có một chuyên mục trail_hiked và vì tôi đang ở ' chế độ tập thể dục cực kỳ hiệu quả 'trong khoảng thời gian gần 3 tháng này, tôi thậm chí còn tính lượng calo trong khi đẩy xe cắt cỏ trên sân:
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)
Tuy nhiên, để giới hạn hơn nữa tập dữ liệu, tôi cũng sẽ lọc ra các hàng đó:
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)
Để đơn giản và dễ sử dụng, tôi sẽ tạo XEM các cột để làm việc với:
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)
Để lại cho tôi bộ dữ liệu này:
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)
Hàm cửa sổ đầu tiên tôi sẽ xem xét là ROW_NUMBER ().
Giả sử tôi muốn một tập hợp kết quả được sắp xếp theo cột burn_calories cho tháng 'tháng 7'.
Tất nhiên, tôi có thể truy xuất dữ liệu đó bằng truy vấn này:
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)
Tuy nhiên, vì bất kỳ lý do gì (có thể là sự hài lòng cá nhân), tôi muốn trao giải a xếp hạng trong số các hàng được trả về bắt đầu bằng 1 biểu thị về số lượng Burn_calories cao nhất, đến (n) hàng trong tập kết quả.
ROW_NUMBER (), hoàn toàn có thể xử lý vấn đề này:
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)
Bạn có thể thấy hàng có số lượng burn_calories là 386,4 có vị trí 1, trong khi hàng có giá trị 322,9 có 22, là số lượng ít nhất (hoặc thấp nhất) trong số các hàng trả về được đặt.
Tôi sẽ sử dụng ROW_NUMBER () cho điều gì đó thú vị hơn một chút khi chúng ta tiến hành. Chỉ khi tôi biết về nó được sử dụng trong bối cảnh đó, tôi mới thực sự nhận ra sức mạnh thực sự của nó.
Tiếp theo, hãy truy cập hàm cửa sổ RANK () để cung cấp một loại ' xếp hạng khác nhau 'giữa các hàng. Chúng tôi vẫn sẽ nhắm mục tiêu giá trị cột Burn_calories. Và, mặc dù RANK () tương tự như ROW_NUMBER () ở chỗ chúng có phần xếp hạng các hàng, nhưng nó tạo ra một sự khác biệt nhỏ trong một số trường hợp nhất định.
Tôi thậm chí sẽ giới hạn hơn nữa số lượng hàng nói chung bằng cách lọc bất kỳ bản ghi nào không phải trong tháng 'tháng 7' mà nhắm mục tiêu theo một đường cụ thể:
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)
Nhận thấy bất cứ điều gì kỳ lạ ở đây? Khác với ROW_NUMBER ()?
Kiểm tra giá trị vị trí cho các hàng '2018-07-22' và '2018-07-27'. Họ đang hòa ở vị trí thứ 3.
Có lý do chính đáng vì giá trị burn_calorie là 378,3 có trong cả hai hàng.
ROW_NUMBER () sẽ xếp hạng chúng như thế nào?
Hãy cùng tìm hiểu:
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)
Hừm ...
Không có ràng buộc nào trong việc đánh số cột vị trí lần này.
Nhưng, ai được ưu tiên?
Theo hiểu biết của tôi, đối với một thứ tự có thể dự đoán được, bạn có thể sẽ phải xác định nó bằng một số phương tiện bổ sung khác trong truy vấn (ví dụ:cột time_walking trong trường hợp này?).
Nhưng chúng tôi vẫn chưa hoàn thành với các tùy chọn xếp hạng. Đây là 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)
Sự ràng buộc vẫn còn, tuy nhiên, việc đánh số khác nhau ở vị trí các hàng được tính , tiếp tục qua các kết quả còn lại.
Trong đó RANK () bắt đầu đếm với 5 sau khi kết thúc, DENSE_RANK () bắt đầu ở số tiếp theo, trong trường hợp này là 4, vì hòa xảy ra ở hàng 3.
Tôi sẽ là người đầu tiên thừa nhận, các mẫu xếp hạng hàng khác nhau này khá thú vị, nhưng, làm thế nào bạn có thể sử dụng chúng để tạo ra một tập hợp kết quả có ý nghĩa?
ClusterControlSingle Console cho Toàn bộ Cơ sở dữ liệu Cơ sở hạ tầng của bạnTìm hiểu những tính năng mới khác trong ClusterControlInstall ClusterControl MIỄN PHÍMột ý tưởng bổ ích
Tôi phải cung cấp tín dụng khi tín dụng đến hạn. Tôi đã học rất nhiều về các chức năng của cửa sổ từ một loạt video tuyệt vời trên YouTube và đặc biệt là một video đã truyền cảm hứng cho tôi về ví dụ tiếp theo này. Hãy ghi nhớ mặc dù các ví dụ trong loạt bài đó được trình bày bằng cơ sở dữ liệu không phải nguồn mở hệ thống (Đừng ném trái cây và rau thối kỹ thuật số vào tôi), có rất nhiều điều để học hỏi từ các video nói chung.
Tôi thấy một mẫu trong hầu hết các kết quả truy vấn cho đến nay mà tôi muốn khám phá. Tôi sẽ không lọc theo tháng cũng như không theo dõi.
Điều tôi muốn biết, là những ngày liên tiếp tôi đã đốt cháy hơn 350 calo. Tốt hơn nữa, các nhóm của những ngày đó.
Đây là truy vấn cơ bản mà tôi sẽ bắt đầu và xây dựng từ:
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)
Chúng tôi đã thấy ROW_NUMBER () rồi, tuy nhiên bây giờ nó mới thực sự phát huy tác dụng.
Để thực hiện công việc này (ít nhất là trong MySQL), tôi đã phải sử dụng hàm DATE_SUB () vì về cơ bản, với kỹ thuật này, chúng tôi đang trừ một số - giá trị được cung cấp bởi ROW_NUMBER () từ cột ngày tháng của cùng một hàng, trong đó lần lượt, cung cấp chính ngày tháng thông qua phép tính:
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)
Tuy nhiên, nếu không có DATE_SUB (), bạn sẽ kết thúc với điều này (hoặc ít nhất là tôi đã làm):
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)
Này, trông không tệ lắm đâu.
Điều gì mang lại?
Ơ, hàng có giá trị positional_bound là '20180698' ...
Chờ một chút, giá trị này được cho là để tính toán giá trị ngày bằng cách trừ số ROW_NUMBER () cung cấp cho cột day_of_walk.
Đúng.
Tôi không biết về bạn, nhưng tôi không biết một tháng có 98 ngày!
Tuy nhiên, nếu có, hãy mang thêm tiền lương!
Tất cả thú vị sang một bên, điều này rõ ràng là không chính xác và đã thúc giục tôi (cuối cùng) sử dụng DATE_SUB (), cung cấp một tập hợp kết quả chính xác, sau đó cho phép tôi chạy truy vấn này:
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)
Các tài nguyên liên quan ClusterControl dành cho MySQL MySQL vào năm 2018:Có gì trong 8.0 và các quan sát khác Đo điểm chuẩn hiệu suất của MySQL:MySQL 5.7 so với MySQL 8.0 Về cơ bản, tôi đã quấn tập hợp kết quả được cung cấp từ truy vấn phân tích đó, dưới dạng Bảng gốc và truy vấn nó cho:ngày bắt đầu và ngày kết thúc, tổng số những gì tôi đã gắn nhãn num_of_hikes, sau đó được nhóm lại trên cột positional_bound, cuối cùng cung cấp các nhóm nhóm những ngày liên tiếp tôi đã đốt cháy hơn 350 calo.
Bạn có thể thấy trong phạm vi ngày từ 2018-06-24 đến 2018-06-26, kết quả là 3 ngày liên tiếp đáp ứng tiêu chí lượng calo đốt cháy là 350 trong điều khoản WHERE.
Không quá tệ nếu bản thân tôi không nói vậy, nhưng chắc chắn là một kỷ lục tôi muốn thử và tốt nhất!
Kết luận
Các chức năng của cửa sổ nằm trong một thế giới và giải đấu của riêng chúng. Tôi thậm chí chưa làm xước bề mặt của chúng, chỉ che 3 trong số chúng ở ' cấp độ cao 'giới thiệu và có lẽ, cảm giác tầm thường. Tuy nhiên, hy vọng rằng thông qua bài đăng này, bạn thấy rằng bạn có thể truy vấn dữ liệu khá thú vị và có tiềm năng sâu sắc với một ' rất tối thiểu 'sử dụng chúng.
Cảm ơn bạn đã đọc.