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.

The post Gửi các em GenZ mê Stored Procedure: “Không phải cứ nhét hết vào SP là ‘pro’ đâu!” first appeared on HaiNH.

Sqlcmd -E -S ATM-5501256-01\SQLEXPRESS -d master -Q" BACKUP DATABASE [HTEN-EPR-CBP-HUNGPHAT] TO DISK = 'C:\BackupSQL\db_%TIME:~0,2%h.bak' WITH INIT"

Tạo file .BAT có nội dung như trên và lưu vào 1 folder “C:\BackupSQL\scripts.bat”, các bạn thay đổi đường dẫn thì tùy. Nếu muốn thêm bước nén file thì sử dụng nội dung file .BAT dưới đây.

Sqlcmd -E -S ATM-5501256-01\SQLEXPRESS -d master -Q" BACKUP DATABASE [HTEN-EPR-CBP-HUNGPHAT] TO DISK = 'C:\BackupSQL\db_%TIME:~0,2%h.bak' WITH INIT"

"C:\Program Files\WinRar\rar.exe"  a -r -ep1 "C:\BackupSQL\db_%TIME:~0,2%h.rar"  "C:\BackupSQL\db_%TIME:~0,2%h.bak"

Del "C:\BackupSQL\db_%TIME:~0,2%h.bak"

Mở Windows Task Schedule để tạo 1 job như các bước dưới đây

Nếu muốn backup lên Cloud nữa thì ta có thể sử dụng Google drive for desktop, cài nó lên và add folder backup vào là sẽ tự syns lên cloud

Ngoài ra nếu syns lên google drive này ta có thể lưu được 100 phiên bản – tức là ta có thể lưu backup sql được trong phạm vi 100 ngày, quá thoải mái để kiểm tra restore khi có sự cố phải không.

The post Sao lưu dữ liệu MS SQL EXPRESS tự động first appeared on HaiNH.

Sử dụng WITH (NOLOCK) có chức năng gì ?

Cho phép SQL đọc dữ liệu từ các bảng kể cả khi đang bị lock mà không bị chặn bởi các tiến trình khác. Việc này giúp cải thiện hiệu suất truy vấn, tuy nhiên có khả năng dữ liệu đọc được bị sai lệch, không chuẩn.

Hãy thử xem ví dụ dưới đây để hiểu rõ hơn nhé:

Đây là một truy vấn trả về tất cả dữ liệu từ bảng Person.Contact (database AdventureWorks). Khi nhìn vào kết quả trả về chúng ta thấy duy nhất có 1 bản ghi có cột Suffix là có giá trị ( khác null), đó là bản ghi có ContactID = 12.

SELECT * FROM Person.Contact WHERE ContactID < 20

Bây giờ hãy thử chạy câu truy vấn dưới đây trên một cửa sổ sql studio management khác với transaction xem sao nhé, tuy nhiên chúng ta sẽ không comit tới database để những bản ghi đó bị khóa lại xem sao:

-- run in query window 1
BEGIN TRAN
UPDATE Person.Contact SET Suffix = 'B' WHERE ContactID < 20
-- ROLLBACK or COMMIT

Nếu chúng ta chạy lại câu lệnh select bên trên kia thì sẽ thấy câu truy vấn này sẽ cứ treo mãi mà không trả về kết quả nào.

SELECT * FROM Person.Contact WHERE ContactID < 20

Nếu chạy lệnh sp_who2  chúng ta có thể biết được là lệnh SELECT đó đã bị block lại. Nguyên nhân là do lệnh UPDATE trên kia chưa được COMIT hoặc ROLLBACK, các bản ghi đó sẽ bị khóa lại, câu truy vấn SELECT kia sẽ bị treo mãi. Khi đó chỉ có cách hủy câu select đó đi hoặc là COMIT, ROLLBACK để lệnh UPDATE trên kia hoàn thành.

Để truy xuất những bản ghi đã bị khóa đó, Chúng ta có thể sử dụng chỉ thị NOLOCK như dưới đây. Câu lệnh SELECT vẫn sẽ trả về kết quả thậm chí lệnh UPDATE trên kia chưa được COMIT hay ROLLBACK và câu lệnh SELECT tại window 1 vẫn đang loading …

-- run in query window 2
SELECT * FROM Person.Contact WITH (NOLOCK) WHERE ContactID < 20

Chúng ta có thể thấy cột Suffix bây giờ tất cả giá trị đều là “B”. Nguyên nhân là do câu lệnh UPDATE tại windows 1 đã thực hiện việc update các bản ghi đó. Mặc dù transaction vẫn chưa được commit nhưng nếu sử dụng chỉ thị NOLOCK thì SQL Server sẽ bỏ qua việc lock và trả về dữ liệu. Nếu trong trường hợp lệnh UPDATE  trên kia được rollback lại thì dữ liệu trả về bị sai lệch, không chuẩn là ở chỗ đó.

Nếu chúng ta rollback lại lệnh UPDATE trên kia bằng lệnh ROLLBACK thì câu lệnh SELECT ở window 1 lúc này cũng sẽ trả về kết quả ta có thể thấy cột Suffix giống như ban đầu.

-- run in query window 1
ROLLBACK

-- run in query window 2
SELECT * FROM Person.Contact WITH (NOLOCK) WHERE ContactID < 20 
-- or
SELECT * FROM Person.Contact WHERE ContactID < 20

Vì vậy với việc sử dụng chỉ thị NOLOCK thì dữ liệu đọc được là đã được thay đổi, tuy nhiên dữ liệu đó chưa thực sự được xác nhận bởi CSDL.  Nếu các bạn đang chạy báo cáo mà không quan tâm đến việc dữ liệu có thể bị ngắt hay không sử dụng transaction thì không vấn đề, nhưng nếu việc tạo transaction và yêu cầu dữ liệu có tính nhất quán thì việc sử dụng chỉ thị NOLOCK có thể khiến dữ liệu báo cáo bị sai hoặc ngắt.

Các kiểu Lock của SQL Server khi suwe dụng với NOLOCK

Nếu chúng ta chạy truy vấn SELECT trên kia mà không có NOLOCK và sử dụng sp_who2 có thể thấy kết quả như sau

Còn vẫn câu truy vấn đó nhưng với NOLOCK và sử dụng sp_who2 có thể thấy kết quả như sau

Điểm khác nhau ở đây là một khóa “S” được đặt trên page (PAG) khi không sử dụng NOLOCK. Tương tự chúng ta thấy khó Sch-S tương tứng với IS cho table (TAB). Vì vậy, các vấn đề chúng ta thấy được là ngay cả khi chúng ta chỉ SELECT dữ liệu thôi nhưng SQL  Server vẫn tạo ra Lock để đảm bảo dữ liệu được nhất quán.

Đây là các kiểu Lock và chế độ Lọc được sử dụng cho cả 2 câu truy vấn select bên trên:

Lock Types:

• MD – metadata lock
• DB – database lock
• TAB – table lock
• PAG – page lock

Lock Mode:

• S – Cho phép truy cập
• Sch-S – Schema được ổn định đảm bảo không thay đổi khi đối tượng đang được sử dụng
• IS – Intent được chia sẻ và chỉ định sử dụng Lock S

READUNCOMMITED và NOLOCK

Chỉ thị NOLOCK tương tự với chỉ thị READUNCOMMITED và cho kết quả giống nhau

SELECT * FROM Person.Contact WITH (READUNCOMMITTED)

With NOLOCK chỉ sử dụng cho lệnh SELECT

Chỉ thị NOLOCK và READUNCOMMITED chỉ được sử dụng duy nhất với lệnh SELECT. Nếu chúng ta sử dụng chúng cho UPDATE, DELETE, INSERT sẽ gặp lỗi.

UPDATE Person.Contact with (NOLOCK) SET Suffix = 'B' WHERE ContactID < 20

[su_highlight background=”#FFFFE1″ color=”#666666″]Msg 1065, Level 15, State 1, Line 15 The NOLOCK and READUNCOMMITTED lock hints are not allowed for target tables of INSERT, UPDATE, DELETE or MERGE statements.[/su_highlight]

Schema thay đổi việc Block với NOLOCK

NOLOCK cần một khóa Sch-S ( ổn định schema ), SELECT sử dụng NOLOCK vẫn có thể bị chặn nếu một bảng bị thay đổi và không được comit. Đây là một ví dụ:

-- run in query window 1
BEGIN TRAN
ALTER TABLE Person.Contact ADD column_b 
VARCHAR(20) NULL ;

Nếu chúng ta chạy câu lệnh SELECT nó vẫn sẽ bị chặn trừ khi chúng ta comit hoặc rollback.

-- run in query window 2
SELECT * FROM Person.Contact WITH (NOLOCK) WHERE ContactID < 20

Các vấn đề với NOLOCK

Chúng ta đã nhắc đến vấn đề dữ liệu có thể không nhất quán nếu sử dụng NOLOCK, dưới đây là một vài vấn đề chúng ta có thể gặp nếu sử dụng nó

• Dirty Reads – Đọc bẩn, điều này xảy ra khi cập nhật được thực hiện, dữ liệu select ra có thể khác nhau.
• Nonrepeatable Reads – Đọc không lặp lại, việc này xảy ra khi chúng ta cần đọc dữ liệu nhiều lần và dữ liệu thay đổi trong quá trình đó.
• Phantom Reads – Đọc ma, việc này xảy ra khi dữ liệu được insert hoặc delete và transaction đã rollback lại. Vì vậy dữ liệu insert mà chúng ta nhận được có thể nhiều hơn thực tế, tương tự số bản ghi bị xóa sẽ ít hơn nếu như rollback được thực hiện.

Các vấn đề khác và chi tiết chúng ta có thể tham khảo tại link : http://msdn.microsoft.com/en-us/library/ms190805.aspx

Isolation Level

Chúng ta cũng có thể thiết lập Isolation Level cho tất cả truy vấn sử dụng NOLOCK hoặc READUNCOMMITTED . Isolation level sẽ chấp nhận READUNCOMMITTED cho tất cả lệnh SELECT cho đến khi chúng ta tắt nó đi.

Trong ví dụ dưới đây, hai câu lệnh SELECT sẽ sử dụng READUNCOMMITED hoặc NOLOCK và UPDATE sẽ vẫn hoạt động như bình thường. Bằng cách này, bạn có thể đặt một loạt các câu lệnh thay vì sửa đổi mỗi truy vấn.

SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED; -- turn it on

SELECT * FROM Person.Contact WHERE ContactID < 20 

UPDATE Person.Contact SET Suffix = 'B' WHERE ContactID = 1 

SELECT * FROM Person.Contact WHERE ContactID < 20 

SET TRANSACTION ISOLATION LEVEL READ COMMITTED; -- turn it off

The post Tìm hiểu về WITH (NOLOCK) trong MS SQL Server first appeared on HaiNH.

VD: Chúng ta có 2 bảng HOC_VIEN (A) và DIEM_THI (B) như dưới đây:

Với 2 bảng dữ liệu trên có liên kết thông qua cột MaHV, vậy làm thế nào chúng ta lấy ra được danh sách điểm thi có các cột môn học, họ tên học viên, mã lớp và điểm số cùng lúc? Khi đó chúng ta cần liên kết hay là JOIN các bảng dữ liệu lại với nhau và chỉ định ra các trường dữ liệu cần lấy.

SQL Server cung cấp các kiểu JOIN là INNER JOIN, OUTER JOIN, và CROSS JOIN.

1. INNER JOIN (viết tắt: JOIN)

Kết quả từ Inner join trong SQL là tập hợp dữ liệu trong đó giá trị dùng để join hai table với nhau đều có ở cả hai bảng, nghĩa là kết quả là GIAO của hai tập hợp dữ liệu.Các bản ghi chỉ xuất hiện ở một trong hai bảng sẽ bị loại.

Câu truy vấn như sau:

SELECT A.MonHoc,A.MaHV,B.HoTen,B.MaLop,A.DiemSo
FROM DIEM_THI A INNER JOIN HOC_VIEN B ON A.MaHV = B.MaHV
-- Hoặc có thể viết tắt --
SELECT A.MonHoc,A.MaHV,B.HoTen,B.MaLop,A.DiemSo
FROM DIEM_THI A JOIN HOC_VIEN B ON A.MaHV = B.MaHV

Kết quả như chúng ta thấy với 6 bản ghi trên thì các giá trị MaHV đều có trong cả 2 bảng HOC_VIEN và DIEM_THI

2. OUTER JOIN trong SQL Server

Lấy về các bản ghi có mặt trong cả hai bảng và cả các bản ghi chỉ xuất hiện ở một trong hai bảng. Kiểu JOIN này được chia làm mấy loại sau:

2.1. LEFT OUTER JOIN (viết tắt: LEFT JOIN)

Lấy toàn bộ các dòng dữ liệu ở table bên trái và với những dòng dữ liệu tương ứng ở bảng bên phải CÓ giá trị MaHV ở bảng bên trái, nếu không có dữ liệu tương ứng bảng bên phải sẽ trả về kết quả null

Câu truy vấn như sau:

SELECT A.MonHoc,A.MaHV,B.HoTen,B.MaLop,A.DiemSo
FROM DIEM_THI A LEFT OUTER JOIN HOC_VIEN B ON A.MaHV = B.MaHV
-- Hoặc có thể viết tắt --
SELECT A.MonHoc,A.MaHV,B.HoTen,B.MaLop,A.DiemSo
FROM DIEM_THI A LEFT JOIN HOC_VIEN B ON A.MaHV = B.MaHV

Kết quả như chúng ta thấy, tất cả các dòng ở bảng DIEM_THI đã được liệt kê ra, một số dòng có cột HoTen và MaLop là null là do nguyên nhân MaHV có ở bảng DIEM_THI nhưng không có ở bảng HOC_VIEN

2.2. RIGHT OUTER JOIN (viết tắt: RIGHT JOIN)

Ngược lại so với LEFT JOIN, lấy toàn bộ các dòng dữ liệu ở table bên phải và với những dòng dữ liệu tương ứng ở bảng bên trái CÓ giá trị MaHV ở bảng bên phải, nếu không có dữ liệu tương ứng bảng bên trái sẽ trả về kết quả null

Câu truy vấn như sau:

SELECT A.MonHoc,A.MaHV,B.MaHV MaHV2,B.HoTen,B.MaLop,A.DiemSo
FROM DIEM_THI A RIGHT OUTER JOIN HOC_VIEN B ON A.MaHV = B.MaHV
-- Hoặc có thể viết tắt --
SELECT A.MonHoc,A.MaHV,B.MaHV MaHV2,B.HoTen,B.MaLop,A.DiemSo
FROM DIEM_THI A RIGHT JOIN HOC_VIEN B ON A.MaHV = B.MaHV

Kết quả như chúng ta thấy tất cả các dòng của bảng HOC_VIEN đã được liệt kê ra, mình thêm cột B.MaHV as MaHV2 ra để các bạn thấy danh sách của nó đầy đủ trong khi cột MaHV, MonHoc,DiemSo là null vì cột MaHV trong bảng DIEM_THI không có trong bảng HOC_VIEN. Các bạn có thể so sánh với bảng kết quả bên trên kia khi select left join nhé.

2.3. FULL OUTER JOIN (viết tắt: FULL JOIN)

Kết quả gồm tất cả các bản ghi của cả hai bảng. Với các bản ghi chỉ xuất hiện trong một bảng thì các cột dữ liệu từ bảng kia được điền giá trị NULL.

Câu truy vấn như sau:

SELECT A.MonHoc,A.MaHV,B.MaHV MaHV2,B.HoTen,B.MaLop,A.DiemSo
FROM DIEM_THI A FULL OUTER JOIN HOC_VIEN B ON A.MaHV = B.MaHV
-- Hoặc có thể viết tắt --
SELECT A.MonHoc,A.MaHV,B.MaHV MaHV2,B.HoTen,B.MaLop,A.DiemSo
FROM DIEM_THI A FULL JOIN HOC_VIEN B ON A.MaHV = B.MaHV

Nhìn kết quả kia thì chúng ta có thể thấy kết quả là bao gồm là những dòng kết quả của LEFT JOIN và RIGHT JOIN kết hợp với nhau, không bao gồm các dòng trùng lặp. Trên kia, những dòng HoTen là null là do MaHV ở bảng DIEM_THI nhưng không có ở bảng HOC_VIEN và những dòng MonHoc,DiemSo là null nguyên nhân do MaHV có ở bảng HOC_VIEN mà không có ở bảng DIEM_THI.

3. CROSS JOIN

CROSS JOIN trong SQL ít được sử dụng hơn so với các loại JOIN ở trên do tính ít ý nghĩa của nó, kết quả trả về của CROSS JOIN là lấy số dòng của bảng bên trái x số dòng của bảng bên phải. Ví dụ bảng DIEM_THI có 12 dòng, bảng HOC_VIEN có 12 dòng, kết quả trả về là 12×12 = 144 dòng.
Dữ liệu được nhân lên do cứ tương ứng với 1 dòng trong DIEM_THI thì sẽ nối với toàn bộ 12 dòng trong HOC_VIEN mà không cần quan tâm đến tiêu chí so sánh nào (không có mệnh đề ON t1.ColumnA = t2.ColumnB như các kiểu JOIN khác).

Câu lệnh truy vấn như sau:

SELECT A.MonHoc,A.MaHV,B.HoTen,B.MaLop,A.DiemSo
FROM DIEM_THI A CROSS JOIN HOC_VIEN B

KẾT BÀI

Chúng ta đã tìm hiểu về các loại JOIN trong SQL Server, chúng được sử dụng thường xuyên trong truy vấn dữ liệu và nhiều xử lý khác. Cho nên bạn cần thực hành cẩn thận và nắm thật rõ cách sử dụng các loại Join để khi làm việc với SQL Server được nhuần nhuyễn và hiệu quả hơn.

The post Phân biệt và cách sử dụng các loại JOIN trong MSSQL Server first appeared on HaiNH.