Dứa Data

Học SQL mỗi ngày cùng Dứa – Tính số ngày nhưng lệch 1 ngày: lỗi rất khó debug

Khi làm việc với dữ liệu thời gian, rất nhiều người sử dụng DATEDIFF để tính số ngày giữa hai mốc. Nhìn qua thì đây là cách làm hoàn toàn hợp lý, nhưng thực tế lại có thể dẫn đến kết quả “lệch” mà bạn không hề nhận ra.

Nguyên nhân là vì DATEDIFF không tính theo khoảng thời gian thực tế, mà tính theo số lần “chuyển ngày”. Chỉ cần hai thời điểm nằm ở hai ngày khác nhau, dù cách nhau chỉ vài phút, kết quả vẫn là 1 ngày.

Ví dụ, một đơn hàng được tạo lúc 23:00 và giao lúc 01:00 hôm sau. Thực tế chỉ cách nhau 2 tiếng, nhưng DATEDIFF(day) sẽ trả về 1. Điều này có thể làm sai hoàn toàn các phân tích liên quan đến thời gian giao hàng hoặc thời gian xử lý.

Đây là một lỗi rất nguy hiểm vì kết quả nhìn qua vẫn “hợp lý”. Bạn thấy có số ngày, có logic, nhưng thực chất không phản ánh đúng thực tế.

Cách xử lý là phải xác định rõ bạn đang muốn đo cái gì: số ngày lịch (calendar day) hay khoảng thời gian thực. Nếu là khoảng thời gian thực, bạn nên tính theo giờ rồi chuyển đổi sang ngày để có kết quả chính xác hơn.

Hiểu rõ cách SQL xử lý thời gian sẽ giúp bạn tránh được những sai lệch rất tinh vi trong phân tích dữ liệu.

Mỗi ngày luyện một chút, tập trung vào bản chất thay vì học thuộc. Dứa sẽ đồng hành cùng bạn trong series này.

Project: Phân tích hiệu quả chiến dịch Marketing đa kênh bằng Excel

Project này phù hợp cho các bạn đang học hoặc làm:
📊 Data Analyst
📈 Business Analyst
📣 Marketing Analyst
💻 Excel cho phân tích dữ liệu

✨ Nội dung project gồm:

- Bối cảnh bài toán thực tế
- Bộ dữ liệu marketing đa kênh
- File Excel phân tích
- KPI như CTR, CPC, CPA, ROAS, Profit

Bộ câu hỏi phân tích
Insight & recommendation như một báo cáo thật

Rất phù hợp để:

học phân tích dữ liệu bằng Excel
làm project portfolio
luyện tư duy business
tham khảo khi làm case study

[Dự án SQL]

7 Case Study - đa dạng domain thực tế cho bạn triển khai từ cơ bản đến nâng cao✅

Học SQL mỗi ngày cùng Dứa – Format date xong rồi GROUP: sai logic mà không ai nhận ra

Khi làm báo cáo, rất nhiều người có thói quen format lại ngày tháng cho đẹp rồi dùng luôn giá trị đó để GROUP BY. Nhìn qua thì kết quả vẫn ra đúng dạng “MM-yyyy”, rất gọn gàng và dễ đọc. Nhưng thực chất, cách làm này tiềm ẩn rất nhiều rủi ro.

Format về bản chất chỉ là chuyển dữ liệu sang dạng hiển thị (text), chứ không còn giữ nguyên kiểu thời gian ban đầu. Khi bạn GROUP BY trên giá trị đã format, SQL đang nhóm theo chuỗi ký tự, không còn theo ý nghĩa thời gian nữa.

Điều này có thể gây ra nhiều vấn đề: hiệu năng kém hơn, khó xử lý tiếp (ví dụ sort lại theo thời gian), và trong một số trường hợp có thể dẫn đến grouping sai nếu format không nhất quán.

Cách tiếp cận đúng là luôn GROUP BY trên dữ liệu gốc (YEAR, MONTH…), sau đó mới format ở bước SELECT để hiển thị. Như vậy bạn vừa đảm bảo logic đúng, vừa giữ được dữ liệu sạch để xử lý tiếp nếu cần.

Một nguyên tắc rất quan trọng khi làm việc với SQL là: format chỉ để hiển thị, không dùng để tính toán. Nếu bạn hiểu và áp dụng đúng nguyên tắc này, bạn sẽ tránh được rất nhiều lỗi tinh vi trong phân tích dữ liệu.

Mỗi ngày luyện một chút, tập trung vào bản chất thay vì học thuộc. Dứa sẽ đồng hành cùng bạn trong series này.

Học SQL mỗi ngày cùng Dứa – Sort date dạng text: nhìn đúng nhưng sai hoàn toàn

Một lỗi rất dễ bị bỏ qua khi làm việc với dữ liệu là bạn đang sort theo ngày, nhưng thực chất cột đó lại đang được lưu dưới dạng text. Khi đó, SQL sẽ không hiểu đây là thời gian, mà chỉ đơn giản là sắp xếp theo thứ tự chữ cái.

Điều này dẫn đến những kết quả rất “lạ” như tháng 10 đứng trước tháng 2, hoặc ngày 2 đứng trước ngày 15. Nhìn qua thì dữ liệu có vẻ vẫn được sắp xếp, nhưng thực chất thứ tự thời gian đã bị sai hoàn toàn.
Nguyên nhân là vì string được so sánh từng ký tự từ trái sang phải, chứ không phải theo ý nghĩa thời gian. Nếu format không chuẩn (ví dụ thiếu số 0 phía trước), thứ tự sẽ bị lệch ngay lập tức.

Đây là lỗi rất nguy hiểm vì nó không gây lỗi query, không có cảnh báo, nhưng lại làm sai toàn bộ việc phân tích theo thời gian.

Cách xử lý đúng là luôn đảm bảo dữ liệu được lưu dưới dạng DATE/DATETIME, hoặc nếu bắt buộc phải làm việc với text thì phải convert về kiểu date trước khi sort hoặc filter.

Hiểu rõ sự khác biệt giữa kiểu dữ liệu sẽ giúp bạn tránh được rất nhiều lỗi “nhìn thì đúng nhưng bản chất lại sai” trong SQL.

Mỗi ngày luyện một chút, tập trung vào bản chất thay vì học thuộc. Dứa sẽ đồng hành cùng bạn trong series này.

Học SQL mỗi ngày cùng Dứa – Month = 1 nhưng lại gộp nhiều năm (lỗi cực khó nhận ra)

Một lỗi rất phổ biến khi làm việc với dữ liệu thời gian là bạn nhìn thấy kết quả GROUP BY theo tháng và nghĩ rằng mọi thứ đang đúng. Nhưng thực tế, phía sau con số đó có thể đang trộn dữ liệu của nhiều năm khác nhau.

Khi bạn dùng MONTH(order_date), SQL chỉ trả về một con số từ 1 đến 12. Con số này chỉ là “nhãn” của tháng, chứ không chứa thông tin về năm. Vì vậy, tất cả các bản ghi có tháng = 1, dù thuộc năm nào, đều bị gom vào cùng một nhóm.

Điều nguy hiểm là kết quả vẫn trông rất “hợp lý”. Bạn sẽ thấy tháng 1 có doanh thu, tháng 2 có doanh thu… nhưng thực chất mỗi con số đó là tổng của nhiều năm khác nhau. Nếu không để ý, bạn có thể đưa ra những kết luận sai hoàn toàn về xu hướng dữ liệu.

Về bản chất, thời gian không chỉ là tháng, mà là một điểm cụ thể trên timeline. Vì vậy, khi group, bạn cần giữ được đầy đủ thông tin của thời điểm đó, thường là kết hợp cả năm và tháng, hoặc dùng format dạng yyyy-MM.

Hiểu được sự khác biệt giữa “giá trị hiển thị” và “ý nghĩa thực tế” của dữ liệu sẽ giúp bạn tránh được những lỗi rất tinh vi trong phân tích.

Mỗi ngày luyện một chút, tập trung vào bản chất thay vì học thuộc. Dứa sẽ đồng hành cùng bạn trong series này.

Học SQL mỗi ngày cùng Dứa – Group theo tháng nhưng bị tách năm (lỗi rất dễ dính)

Khi bắt đầu làm báo cáo theo thời gian, rất nhiều người sẽ nghĩ đơn giản rằng chỉ cần lấy MONTH từ cột ngày rồi GROUP BY là xong. Nhưng thực tế, cách làm này có thể khiến dữ liệu bị sai mà bạn không hề nhận ra.

Khi bạn chỉ group theo MONTH, SQL sẽ gom tất cả các tháng giống nhau lại với nhau, bất kể năm nào. Điều đó có nghĩa là tháng 1 của 2023, 2024, 2025… sẽ bị gộp chung thành một nhóm. Kết quả nhìn vẫn “có vẻ hợp lý”, nhưng thực chất là đang trộn dữ liệu của nhiều năm vào với nhau.

Đây là một lỗi rất nguy hiểm vì nó không gây lỗi query, không báo sai, nhưng lại làm sai hoàn toàn ý nghĩa của dữ liệu. Đặc biệt trong các báo cáo theo tháng, bạn sẽ không còn phân biệt được xu hướng theo từng năm.

Cách đúng là luôn phải xác định rõ granularity của dữ liệu. Nếu bạn đang phân tích theo tháng trong từng năm, thì phải group theo cả YEAR và MONTH. Khi đó mỗi nhóm sẽ đại diện cho một tháng cụ thể trong một năm cụ thể.

Hiểu được granularity không chỉ giúp bạn viết GROUP BY đúng, mà còn là nền tảng để làm phân tích dữ liệu một cách chính xác.

Mỗi ngày luyện một chút, tập trung vào bản chất thay vì học thuộc. Dứa sẽ đồng hành cùng bạn trong series này.

📣 [MENTOR] PHÂN TÍCH DỮ THỰC CHIẾN DỮ LIỆU TÀI CHÍNH - NGÂN HÀNG

Sau một thời gian phát triển cộng đồng, DỨA đã có cơ hội gặp gỡ nhiều anh em đang theo đuổi lĩnh vực Data Analysis nói riêng và Data nói chung. Qua rất nhiều cuộc trò chuyện, mình nhận ra một điểm chung:

Nhiều bạn học công cụ rất nhanh, làm bài tập cũng ổn, nhưng khi gặp bài toán thực tế trong doanh nghiệp thì lại dễ bối rối:

- Không biết bắt đầu từ đâu
- Không hiểu rõ ngữ cảnh bài toán
- Chưa nắm được nghiệp vụ dữ liệu trong môi trường thực tế

Và đó cũng là lý do DỨA xây dựng lộ trình:

🔥 “PHÂN TÍCH DỮ THỰC CHIẾN DỮ LIỆU TÀI CHÍNH - NGÂN HÀNG”

Dành cho các bạn trái ngành, hoặc các bạn muốn theo đuổi con đường Data trong doanh nghiệp tài chính, ngân hàng, fintech.

Đây không phải là một khóa chỉ học công cụ.
Điểm khác biệt của chương trình là bạn sẽ được tiếp cận bài toán thực tế trong domain Tài chính - Ngân hàng, nơi yêu cầu không chỉ biết SQL, Excel, BI hay Python, mà còn phải hiểu:

✅ Nghiệp vụ dữ liệu trong ngân hàng
✅ Cách tiếp cận và phân tích bài toán thực tế
✅ Tư duy xử lý dữ liệu trong môi trường đi làm
✅ Kỹ năng làm việc với báo cáo và yêu cầu nghiệp vụ

Trong lộ trình này, các bạn sẽ được làm quen với nhiều nhóm bài toán thực tế như:

* Quản lý rủi ro
* Quản lý tài sản đảm bảo
* Tính toán tiền lãi
* Báo cáo tuân thủ
* Trích lập dự phòng rủi ro
* Và nhiều tình huống thường gặp trong môi trường tài chính - ngân hàng

Vì đây là chương trình thiên về thực chiến và nghiệp vụ thực tế, nên DỨA tuyển mentee với tiêu chí khá kỹ, học sẽ có bài test đầu vào!

Mình cần các bạn thật sự chăm chỉ, nghiêm túc và sẵn sàng học sâu, vì khối lượng nghiệp vụ và bài tập bám sát công việc thực tế sẽ tương đối nặng.

📌 DỨA TỔNG HỢP CÁC WEBSITE THỰC HÀNH SQL UY TÍN QUỐC TẾ

Nơi để học tập, luyện tập và nâng trình SQL từ cơ bản đến nâng cao dành cho các bạn đang theo đuổi Data, BA, DA, Developer hoặc muốn làm quen với cơ sở dữ liệu.

Nếu bạn đang học SQL mà chưa biết nên bắt đầu từ đâu, hoặc muốn tìm thêm nơi để vừa học vừa thực hành, thì dưới đây là những nền tảng rất đáng để lưu lại:

Học SQL mỗi ngày cùng Dứa – BETWEEN với DATETIME: mất dữ liệu lúc 23:59:59

Nhiều người học SQL được dạy rằng BETWEEN là cách nhanh nhất để lọc theo khoảng thời gian.

Nhưng khi áp dụng vào dữ liệu thực tế, đặc biệt là DATETIME, thì đây lại là một cái bẫy rất dễ mắc phải.
Về lý thuyết, BETWEEN bao gồm cả giá trị đầu và cuối. Nhưng vấn đề là khi bạn viết '2024-04-30', SQL sẽ hiểu là 2024-04-30 00:00:00. Điều này có nghĩa là tất cả dữ liệu trong ngày 30 sau thời điểm 00:00:00 sẽ không được tính vào.

Nói cách khác, bạn tưởng mình đang lấy đến hết ngày 30, nhưng thực tế chỉ lấy đúng thời điểm bắt đầu ngày đó. Toàn bộ dữ liệu trong ngày, đặc biệt là các giao dịch buổi chiều và tối, sẽ bị bỏ sót.

Đây là lý do vì sao rất nhiều báo cáo theo tháng bị thiếu dữ liệu mà không ai nhận ra. Query nhìn hoàn toàn hợp lý, nhưng lại sai về bản chất thời gian.

Cách xử lý đúng là không nên dùng BETWEEN với DATETIME theo kiểu này, mà nên chuyển sang dùng khoảng mở: từ ngày bắt đầu đến trước ngày kế tiếp. Cách này đảm bảo bạn lấy trọn vẹn dữ liệu mà không bị phụ thuộc vào phần giờ.

Hiểu rõ cách SQL xử lý khoảng thời gian sẽ giúp bạn tránh được những lỗi rất “âm thầm” nhưng ảnh hưởng lớn đến kết quả phân tích.

Mỗi ngày luyện một chút, tập trung vào bản chất thay vì học thuộc. Dứa sẽ đồng hành cùng bạn trong series này.

📘 Một cuốn sách mình nghĩ nhiều bạn học Data nên đọc

Không dạy bạn cách dùng Power BI
Mà dạy bạn cách làm dashboard có ý nghĩa

Đôi khi, không phải làm thêm
Mà là học cách bỏ bớt

- Để người xem nhìn vào là hiểu
- Và có thể ra quyết định ngay

Nếu bạn đang học Data Analyst
→ Highly recommend

Học SQL mỗi ngày cùng Dứa – Lọc “hôm nay” nhưng timezone khác → sai kết quả

Một lỗi rất khó nhận ra khi làm việc với dữ liệu thời gian là bạn đang lọc “hôm nay”, nhưng kết quả lại không đúng như mong đợi. Có lúc thiếu dữ liệu, có lúc lại thừa sang ngày hôm trước hoặc hôm sau.

Nguyên nhân không nằm ở câu query, mà nằm ở timezone. Dữ liệu trong database có thể được lưu theo UTC, trong khi hệ thống hoặc server SQL lại đang chạy theo một múi giờ khác. Khi bạn dùng các hàm như CURRENT_DATE hoặc NOW(), SQL sẽ lấy thời gian theo timezone của server, không phải theo timezone của dữ liệu.

Điều này dẫn đến việc “hôm nay” trong query không trùng với “hôm nay” trong dữ liệu, và kết quả bị lệch mà bạn rất khó phát hiện nếu không để ý kỹ.

Trong thực tế, đây là lỗi rất phổ biến khi làm việc với hệ thống quốc tế, nơi dữ liệu được ghi nhận ở nhiều múi giờ khác nhau. Nếu không xử lý đúng, các báo cáo theo ngày có thể sai lệch hoàn toàn.

Cách tiếp cận đúng là luôn xác định rõ timezone của dữ liệu và timezone của hệ thống, sau đó quy về cùng một chuẩn trước khi filter. Tùy vào từng database, bạn có thể dùng các hàm chuyển đổi timezone để đảm bảo tính nhất quán.

Hiểu được timezone không chỉ giúp bạn viết query đúng hơn, mà còn giúp bạn tránh những sai lệch rất nguy hiểm trong phân tích dữ liệu theo thời gian.
Mỗi ngày luyện một chút, tập trung vào bản chất thay vì học thuộc. Dứa sẽ đồng hành cùng bạn trong series này.