Mẹo #4: Thói quen lập trình SQL tốt nhất

Trong bài này chúng ta cùng học về các thói quen tốt nhất khi làm việc với SQL

Không dùng tiền tố 'sp_' trong tên của thủ tục

Đoạn script sau đây trả về tất cả các thủ tục của hệ thống, 1390 thủ tục thuộc hệ thống trong trường hợp này và tất cả bắt đầu với tiền tố 'sp_'

1. SELECT QUOTENAME(SCHEMA_NAME(SCHEMA_ID))+'.'+QUOTENAME(NAME)) AS SystemProcedures  
2. FROM sys.all_objects  
3. WHERE TYPE='P' AND is_ms_shipped=1

   
    
Bây giờ nếu chúng ta tạo các thủ tục với cùng tiền tố 'sp_', thì có hai điều xảy ra bên trong hệ thống:
1. Trong khi thực thi thủ tục của bạn, đầu tiên hệ thống sẽ quét tất cả các thủ tục thuộc hệ thống, và sau đó là các thủ tục chúng ta định nghĩa. Điều này có nghĩa là các thủ tục sẽ mất nhiều thời gian hơn để thực thi. Vì vậy nó làm giảm hiệu suất
2. Nếu trong khi quét các thủ tục hệ thống, có một cái phù hợp, ví dụ tên thủ tục của bạn trùng với tên thủ tục của hệ thống. Thủ tục của hệ thống sẽ luôn luôn được thực thi
Bởi vì điều này, bạn có thể nhận về các kết quả không mong đợi, nó có thể là một ngoại lệ, lỗi hoặc một vài thông tin liên quan đến hệ thống. Và có thể bạn sẽ chẳng bao giờ hiểu được lý do đằng sau nó. Vậy như đã nói tốt nhất là nên tránh sử dụng tiền tố 'sp_' cho tên thủ tục.

Ngừng sử dụng select (*)

Chọn tất cả các cột từ một bảng trở nên dễ dàng bằng việc sử dụng select (*) vì thế chúng ta không cần liệt kê các tên tột một cách riêng lẻ. Nhưng sử dụng cách tiếp cận này có thể dẫn đến một vài vấn đề:
1. Select (*) trả về các cột có thứ tự giống như lúc được định nghĩa trong lúc thiết kế bảng. Vì thế nếu muốn kết quả đòi hỏi các cột theo thứ tự khác. Sử dụng cách tiếp cận này sẽ không có tác dụng.
2. Cho rằng chúng ta có bảng 'Product' có các cột như sau:



Chúng ta viết lệnh SQL để sao chép tất cả các sản phẩm có ProductType là 'Electronic' từ bảng Product sang bảng 'ElectronicProducts'

INSERT INTO ElectronicProducts SELECT * FROM ProductMaster WHERE ProductType='Electric'

Câu lệnh này làm việc một cách hoàn hảo, nhưng có một lúc nào đó trong tương lai chúng ta thêm cột khác vào bảng 'Product' và bây giờ cấu trúc của nó sẽ là:



Và nếu bây giờ, nếu bạn chạy đoạn lệnh SQL ở trên nó sẽ sinh ra một lỗi:


Thay vào đó nếu chúng ta viết đoạn mã như sau:

1. INSERT INTO ElectronicProducts   
2. SELECT ProductID,ProductName,ProductType,ProductCost FROM ProductMaster WHERE ProductType='Electric'  

Thì nó sẽ được thực hiện trong tất cả các trường hợp

Thậm chí là những câu truy vấn đơn giản cũng luôn nghĩ đến hiệu suất

Giả sử bạn đang thiết kế một hệ thống quản lý nhân viên ở đó có một lựa chọn tìm kiếm nhân viên theo tên nhân viên
Bạn viết đoạn mã sau để tìm kiếm và hiển thị chi tiết nhân viên:

SELECT EmployeeID, EmployeeName, EmployeeSalary, EmployeeDepartment FROM Employee 
WHERE EmployeeName='Jacob'

Bây giờ đoạn mã cũng như hệ thống vẫn chạy tốt và không có nhiều bản ghi lắm có thể là 1000. Nhưng bây giờ cho rằng sau một vài năm nữa và dữ liệu chứa hàng triệu bản ghi, đoạn mã trên vẫn có cùng hiệu suất như trước không?
Câu trả lời là KHÔNG, nó mất nhiều thời gian hơn để quét một bảng có hàng triệu bản ghi hơn là bảng chỉ có 1000 bản ghi. Vì thế chúng ta nên luôn luôn nghĩ về hiệu suất trong tương lai trong khi viết mã, thậm chí là ngay cả những đoạn mã đơn giản.
Trong trường hợp này, để tìm kiếm nhanh hơn chúng ta nên tạo index trên trường EmployeeName.
Index có thể được tạo qua đoạn mã sau:

CREATE INDEX EmployeeNameIndex ON Employee(EmployeeName) 

Share on Google Plus

About Practice makes perfect

Chia sẻ cũng là một cách để học được nhiều hơn.
Có công mài sắt có ngày nên kim - Practice makes perfect