Skip to main content

7 posts tagged with "Fundamentals"

Core concepts every developer relies on, regardless of language or framework.

View All Tags

Your Running Total Is Wrong on the First Row: Window Functions, RANGE, and the Default Nobody Reads

· 12 min read
Nguyễn Huỳnh Minh Tiến
Middle Fullstack Developer @ Utop.vn
Summary

GROUP BY collapses rows; a window function keeps every row while still computing the group total. Measured: on the same 200,000-row table, GROUP BY returns 200 rows and the window returns 200,000 rows. It is also faster than the old approach — replacing a self-join with a window took the query from 79.2 ms down to 22.7 ms. But there is one default that quietly corrupts numbers and almost nobody reads it: OVER (ORDER BY ...) uses a RANGE frame, so every peer row receives the same running total. If you want a row-by-row cumulative sum, you must spell out ROWS.

Window functions turn long-winded reporting queries into a few readable lines. They also carry exactly one trap subtle enough to pass code review: a running total that looks plausible in the middle and is wrong wherever values tie.

This post goes deeper into Recursive Queries and Window Functions from the 30-day SQL series. Every number here was measured on PostgreSQL 16.11.

Your LEFT JOIN Became an INNER JOIN and Nothing Warned You

· 11 min read
Nguyễn Huỳnh Minh Tiến
Middle Fullstack Developer @ Utop.vn
Summary

LEFT JOIN keeps every row from the left table and fills in NULL where nothing matches. But WHERE runs after the join, so any condition placed on a right-hand column also removes those NULL rows — and the LEFT JOIN becomes an INNER JOIN with no warning whatsoever. Measured on PostgreSQL 16: a plain LEFT JOIN gives 4 rows, adding WHERE leaves 2 rows, but moving that same condition into ON gives 3 rows — which is the correct answer.

This is the bug I see most often in reporting queries. It is not a syntax error, it is not slow, it throws nothing. It simply returns too few rows, and usually it is precisely the important ones that go missing: customers with no orders yet, products that have never sold, salespeople who have not closed anything.

This post drills into the JOIN lesson from my 30-day SQL series. Every number below is real output from PostgreSQL 16.11.

Why Does Your NOT IN Return Zero Rows? SQL's Three-Valued Logic and the NULL Trap

· 12 min read
Nguyễn Huỳnh Minh Tiến
Middle Fullstack Developer @ Utop.vn
Summary

NULL in SQL is not a value — it is a marker meaning "unknown". Every comparison against it yields UNKNOWN, and WHERE only keeps rows that evaluate to TRUE, so UNKNOWN is discarded exactly like FALSE. The most serious consequence lands on NOT IN: a single NULL anywhere in the subquery makes the entire query return zero rows, even when the data plainly exists. I ran it on PostgreSQL 16: with the same intent, NOT IN returns 0 rows while NOT EXISTS returns 3. No error, no warning — the query just quietly returns the wrong answer.

This is not the kind of bug that crashes an application. It just makes a report short by a few numbers, makes a list screen empty, makes a campaign miss some customers — and leaves nothing behind in the logs.

This post drills into one detail from my 30-day SQL series, specifically the lessons on operators and expressions and subqueries. Every number below is real output from PostgreSQL 16.11.

Giới thiệu UUID (Universally Unique Identifier) - Định danh duy nhất toàn cầu

· 13 min read
Nguyễn Huỳnh Minh Tiến
Middle Fullstack Developer @ Utop.vn
Summary

UUID (Universally Unique Identifier) là chuẩn định danh 128-bit được sử dụng rộng rãi trong lập trình và cơ sở dữ liệu để tạo ID duy nhất toàn cầu mà không cần cơ quan trung tâm quản lý. Bài viết giới thiệu 5 phiên bản UUID (v1 time-based, v4 random, v3/v5 name-based), ưu nhược điểm của từng loại, cách sử dụng trong các ngôn ngữ lập trình phổ biến, và các use case thực tế trong distributed systems, microservices và database design.

UUID (Universally Unique Identifier) là một chuẩn định danh duy nhất được sử dụng rộng rãi trong lập trình và cơ sở dữ liệu. Trong bài viết này, chúng ta sẽ tìm hiểu chi tiết về UUID, tại sao nên sử dụng nó, ưu nhược điểm và các ví dụ thực tế.

AI-DD: Phát Triển Phần Mềm AI-Driven - Series Toàn Diện

· 7 min read
Nguyễn Huỳnh Minh Tiến
Middle Fullstack Developer @ Utop.vn
Summary

AI-DD (AI-Driven Development) là phương pháp phát triển phần mềm do AI dẫn dắt, khác biệt hoàn toàn với việc chỉ sử dụng AI để hỗ trợ. Series này cung cấp roadmap đầy đủ từ hiểu biết cơ bản đến áp dụng thực tế, giúp developers tăng 3-5x năng suất, team leads giảm 50-67% development cycle, và CTOs có strategic roadmap cho AI transformation. Series gồm 4 phần: Giới thiệu và Tác động, Công cụ AI và Case Studies, Số liệu và Kinh nghiệm Thực tế, Tương lai và Kết luận.

Chào mừng bạn đến với series toàn diện về AI-DD (AI-Driven Development) - một cuộc cách mạng đang thay đổi hoàn toàn ngành công nghệ. Series này sẽ đưa bạn từ hiểu biết cơ bản về AI-driven development đến việc áp dụng thực tế và nhìn xa về tương lai của kỹ thuật phần mềm.

Phần lý thuyết nằm ở series này; còn thứ thực sự đưa cho agent đọc thì nằm ở mục Agent Skills — các bộ guideline viết sẵn để agent bám theo khi sinh code.