Chào các đồng nghiệp tương lai,

Dạo này lướt TikTok, Facebook, thỉnh thoảng tôi – một “fossil” (hóa thạch) freelancer ~U40 – lại thấy các bạn tranh luận nảy lửa. Chủ đề hot nhất có vẻ là: “Code nghiệp dư mới viết query trực tiếp, ‘pro’ phải dùng Stored Procedure (SP) cho mọi thứ!”.

Nghe xong, tôi chỉ biết cười trừ, lắc đầu nhớ lại thời “trẻ trâu” của mình.

Các bạn nói SP bảo mật hơn (chống SQL Injection), chạy nhanh hơn (vì pre-compiled), tái sử dụng tốt hơn… Vâng, về lý thuyết, sách giáo khoa viết thế, không sai!

Nhưng các bạn à, sách giáo khoa nó khác với cái “thực tế phũ phàng” khi các bạn đi làm, nhất là freelancer, va chạm với 10 loại dự án, 5 loại khách hàng, và 3 loại “deadline dí sml” (sấp mặt luôn).

Là một người đã từng “thề non hẹn biển” chỉ dùng SP, đây là lý do tôi phải “quay xe” trong 80% các dự án hiện đại:

1. Ác mộng mang tên “Version Control” (Quản lý phiên bản)

Đây là cái “đau” nhất.

Code ứng dụng (C#, Java, Node.js) của các bạn nằm gọn gàng trên Git. Bạn feature/them-chuc-nang-A, bạn fix/bug-B. Mọi thứ rõ ràng.

Giờ bạn dùng SP. Cái SP đó nằm ở đâu? Nó nằm dưới Database.

Bạn sửa 1 cái SP. Làm sao bạn đồng bộ nó với cái branch code của em? Bạn viết script ALTER PROCEDURE à? Bạn commit cái file .sql đó lên Git à?

Rồi 10 ông dev cùng sửa 1 cái SP? Merge kiểu gì? Khóc thét!

Chưa kể dự án có CI/CD (DevOps). Deploy code thì dễ, auto-deploy thay đổi database (mà cụ thể là SP) nó là cả một câu chuyện “đau thương” mà chỉ người trong cuộc mới hiểu. Trong khi dùng ORM (như Entity Framework, TypeORM), mình chỉ cần “Code-First” rồi chạy migration, khỏe re.

2. “Đi tìm logic” – Cuộc phiêu lưu mệt mỏi

Dự án to lên, business logic (logic nghiệp vụ) bắt đầu phức tạp. Khi dùng SP, logic của các bạn bị xé ra làm hai:

• Một nửa nằm trong code (Application Layer).
• Một nửa nằm trong Database (Stored Procedures).

Tưởng tượng bạn nhận bug: “Anh ơi, sao đơn hàng X không tự động giảm giá 10%?”.

Bạn bắt đầu hành trình: Lục code… không thấy. À, chắc nó nằm dưới SP. Bạn mở cái sp_CalculateOrderTotal dài 1000 dòng, viết bằng T-SQL (thứ ngôn ngữ “tù” hơn C# hay JS vạn lần), với 15 cái IF...ELSE, 10 cái JOIN, 5 cái TEMP TABLE.

Bạn debug cái SP đó kiểu gì? PRINT à? Chúc bạn may mắn.

Trong khi nếu logic nằm hết trong code, mình chỉ cần đặt “breakpoint”, F10, F11 vài phát là ra bug.

3. “Khóa cổ” vào một Database (Vendor Lock-in)

Đây là cái freelancer rất sợ. Hôm nay bạn viết 500 cái SP bằng T-SQL cho SQL Server. Mọi thứ chạy mượt. Ngày mai, khách hàng bảo: “Ngân sách eo hẹp quá, mình chuyển sang PostgreSQL (miễn phí) đi em.”

Toang!

Toàn bộ 500 cái SP đó (vốn chứa logic nghiệp vụ) gần như phải viết lại từ đầu vì cú pháp khác nhau.

Nếu bạn viết logic trong code (dùng ORM), bạn chỉ cần đổi cái “ConnectionString”, cài cái “Provider” (driver) cho Postgres. Xong! Code nghiệp vụ giữ nguyên 99%.

4. Cái “Nhanh hơn” nó có thật sự “Nhanh”?

Ngày xưa, 15-20 năm trước, SP nhanh hơn rõ rệt. Giờ thì sao? Các ORM hiện đại quá thông minh rồi. Chúng biết “parameterize” (chống SQL Injection y hệt SP), biết “caching query plan” (cũng gần như pre-compiled).

Trừ khi bạn làm báo cáo (reporting) siêu nặng, xử lý dữ liệu hàng loạt (batch processing) cả triệu record, còn với 90% các nghiệp vụ CRUD (Create, Read, Update, Delete) thông thường, sự chênh lệch hiệu năng giữa SP và một câu query tối ưu (viết bằng Dapper hay EF Core) là không đáng kể.

Đánh đổi sự “nhanh hơn 0.01 giây” để lấy mớ “ác mộng” ở mục 1, 2, 3? Mình xin kiếu.

---

😱 Khi nào thì “ông chú” này dùng SP?

Tất nhiên, SP không phải là rác. Mình vẫn dùng khi:

1. Làm báo cáo phức tạp: Những cái query JOIN 10 bảng, GROUP BY 5 tầng, PIVOT các kiểu. Nhét nó vào SP cho gọn code.
2. Xử lý dữ liệu lớn/theo lô: Cần import/export 1 triệu dòng, chạy job đêm… SP xử lý mấy cái này “nuốt” tốt hơn code ứng dụng.
3. Bảo mật cực cao: Một số nghiệp vụ yêu cầu ứng dụng không được phép SELECT trực tiếp vào bảng, mà chỉ được gọi qua SP (đã được phân quyền EXECUTE) để che giấu cấu trúc bảng. (Hiếm, nhưng có).

---

💡 Túm cái váy lại…

Các bạn à, nghề lập trình không có “viên đạn bạc” (silver bullet) – tức là không có công nghệ nào “đúng” cho mọi trường hợp.

Việc các bạn cuồng tín SP (hoặc bất cứ thứ gì) và chê bai cách làm khác chỉ cho thấy các bạn … chưa “va chạm” đủ nhiều thôi.

Hãy dùng não, phân tích bối cảnh dự án, ưu nhược điểm của từng cái, rồi hãy chọn. Đừng vì thấy ai đó trên TikTok bảo “dùng SP mới pro” mà vội tin sái cổ.

Tools (công cụ) là để phục vụ mình, chứ đừng làm nô lệ cho tools.

Thân ái và chúc bớt “cuồng tín”! Một Freelancer già hay lướt TikTok.