MySQL View là gì? Khi nào nên sử dụng và khi nào không nên?

1. MySQL View là gì?

View trong MySQL là một bảng ảo (Virtual Table) được tạo ra từ câu lệnh SELECT.

Thay vì phải viết lại một truy vấn phức tạp nhiều lần, chúng ta có thể tạo một View và sử dụng nó như một bảng thông thường.

Ví dụ:

CREATE VIEW active_users AS
SELECT id, name, email
FROM users
WHERE status = 1;

Sau khi tạo View, chúng ta có thể truy vấn:

SELECT * FROM active_users;

Lưu ý: View thông thường không lưu trữ dữ liệu riêng. Khi truy vấn View, MySQL sẽ thực thi truy vấn được định nghĩa bên trong View.

2. Khi nào nên sử dụng View?

2.1. Tái sử dụng những truy vấn phức tạp

Khi một truy vấn có nhiều điều kiện JOIN, WHERE hoặc GROUP BY và được sử dụng ở nhiều nơi, View giúp tái sử dụng logic truy vấn.

Thay vì viết lại toàn bộ SQL, chúng ta chỉ cần truy vấn View.

2.2. Đơn giản hóa việc truy vấn dữ liệu

Ví dụ hệ thống có các bảng:

• orders
• users
• order_items

Nếu thường xuyên cần lấy thông tin đơn hàng kèm tên khách hàng và tổng giá trị, chúng ta có thể tạo View để đơn giản hóa truy vấn.

2.3. Giới hạn quyền truy cập dữ liệu

View có thể chỉ hiển thị những cột cần thiết, giúp hạn chế việc truy cập trực tiếp vào các thông tin nhạy cảm.

Ví dụ:

CREATE VIEW public_users AS
SELECT id, name
FROM users;

Người dùng được cấp quyền truy cập View có thể xem tên và ID mà không cần truy cập trực tiếp vào toàn bộ bảng users.

3. Khi nào không nên sử dụng View?

3.1. Khi nghĩ rằng View sẽ giúp truy vấn nhanh hơn

Đây là một hiểu lầm khá phổ biến.

View thông thường không tự động cache kết quả hay lưu dữ liệu đã tính toán. MySQL vẫn phải xử lý truy vấn bên trong View.

Vì vậy, nếu truy vấn gốc chậm thì việc đưa truy vấn đó vào View không đồng nghĩa với việc nó sẽ nhanh hơn.

3.2. Khi truy vấn có quá nhiều tầng View

Ví dụ:

• View A sử dụng View B.
• View B sử dụng View C.
• View C JOIN nhiều bảng khác.

Việc lồng quá nhiều View khiến SQL khó theo dõi, khó tối ưu và khó xác định nguyên nhân khi xảy ra vấn đề hiệu năng.

3.3. Khi logic nghiệp vụ thường xuyên thay đổi

Nếu một truy vấn chứa nhiều điều kiện nghiệp vụ phức tạp và thay đổi liên tục, việc đưa toàn bộ logic vào View có thể khiến quá trình bảo trì khó khăn hơn.

Trong trường hợp này, nên cân nhắc xử lý tại tầng Service hoặc Repository của ứng dụng.

4. View có thay thế được Summary Table không?

Không.

Hai khái niệm này có mục đích khác nhau:

Nếu hệ thống cần thống kê hàng triệu bản ghi và truy vấn báo cáo thường xuyên, Summary Table có thể là lựa chọn phù hợp hơn.

5. Sử dụng View trong Laravel

Trong Laravel, chúng ta có thể truy vấn View tương tự như một bảng thông thường.

Ví dụ:

$users = DB::table('active_users')->get();

Hoặc tạo Model:

class ActiveUser extends Model
{
    protected $table = 'active_users';

    public $timestamps = false;
}

Tuy nhiên, cần lưu ý rằng View thường phù hợp với các thao tác đọc dữ liệu. Không nên mặc định rằng mọi View đều hỗ trợ INSERT, UPDATE hoặc DELETE.

6. Kết luận

MySQL View là một công cụ hữu ích để tái sử dụng truy vấn, đơn giản hóa SQL và giới hạn quyền truy cập dữ liệu.

Tuy nhiên, View không phải công cụ tối ưu hiệu năng mặc định.

Trước khi sử dụng, hãy xác định rõ mục đích:

• Cần tái sử dụng truy vấn? Có thể dùng View.
• Cần đơn giản hóa SQL? Có thể dùng View.
• Cần thống kê dữ liệu lớn với tốc độ đọc cao? Cân nhắc Summary Table.
• Logic nghiệp vụ thay đổi thường xuyên? Nên cân nhắc xử lý tại tầng ứng dụng.

Nguyên tắc quan trọng: Không nên sử dụng View chỉ vì muốn kiến trúc trông gọn gàng hơn. Hãy sử dụng khi nó thực sự giúp hệ thống dễ đọc, dễ bảo trì và phù hợp với nhu cầu thực tế.