Hỏi về cách xử lí quan hệ nhiều-nhiều trong MySQL

Chào các bác, em có câu hỏi như thế này
Trong CSDL, thường thì em hay chia quan hệ nhiều-nhiều theo hướng tạo bảng phụ chứa PK của bảng như thế này.

Nhưng khi có nhiều quan hệ hơn thì em phải join rất nhiều bảng, gây ra nặng cho hệ thống và load dữ liệu khá lâu. Vậy cho em hỏi có cách nào để xử lí quan hệ kiểu nhiều-nhiều để cho dễ quản lí không?

Em cảm ơn

Quan hệ nhiều nhiều thì 3 bảng là bình thường chứ sao. JOIN 3 bảng cũng không phải vấn đề lớn lắm, nếu bạn thấy chạy vẫn ổn, performance vẫn đảm bảo yêu cầu thì chưa cần nghĩ tới các giải pháp cao siêu.

Nếu dữ liệu chủ yếu là để get, ít set thì bạn có thể cache lại ở server.

8 Likes

Bạn chưa thấy câu query hơn trăm dòng nên bạn nghĩ join có 3 bảng là nhiều thôi, chứ việc đó rất bình thường
Bạn có thể tham khảo view hoặc store procedure cho vấn đề của bạn

9 Likes

Sao biết load dữ liệu lâu? Khi thiết kế điều đâu tiên phải đúng đã, đảm bảo các function yêu cầu.
Có nhanh chậm là non-function, cái này quan tâm sau.

Rules of Optimization:
Rule 1: Don’t do it.
Rule 2 (for experts only): Don’t do it yet.

9 Likes

Tớ đã từng được thấy câu query dài cả gần 6 trang a4 và tớ nghĩ cái này chưa phải vấn đề đâu :kissing:

4 Likes

@blacku9

Hi em,

Trong CSDL, thường thì em hay chia quan hệ nhiều-nhiều theo hướng tạo bảng phụ chứa PK của bảng như thế này.

Nhưng khi có nhiều quan hệ hơn thì em phải join rất nhiều bảng, gây ra nặng cho hệ thống và load dữ liệu khá lâu.

Anh thấy cách design bảng quan hệ n-n như trên là khá bình thường.
Ở đây em nói là gây nặng hệ thống và load dữ liệu khá là lâu thì nó do nhiều nguyên nhân, có thể là một trong số dưới đây:

  • Em viết query có vấn đề nên nó chạy chậm ( ví dụ em select * không limit chẳng hạn )
  • Dữ liệu em quá lớn.
  • Server em quá yếu để đáp ứng được lượng request hoặc độ lớn data.

=> Em nên nêu ra thêm thông tin nếu muốn mọi người tư vấn!!!

Vậy cho em hỏi có cách nào để xử lí quan hệ kiểu nhiều-nhiều để cho dễ quản lí không?

Ở đây em phải phân định rõ 2 khái niệm “dễ quản lý” và “truy vấn nhanh (performance tốt)”.
Anh chưa biết em đang định nghĩa như thế nào là “dễ quản lý”?

Còn đối với trường hợp muốn tối ưu về tốc độ truy vấn, thì em phải design table sao cho phù hợp với mục đích truy vấn (business use cases) và ăn index nhiều nhất.

Anh ví dụ:
Giả sử nghiệp vụ em cần làm là với mỗi “Post” cần lấy ra danh sách “Tag” của nó, và lượng dữ liệu em quá lớn dẫn đến join không nổi thì em có thể làm đơn giản là:

  • Bước 1: Không cần thông qua bảng nối trung gian “tags_in_post”, mà lưu thẳng “Tag ID” vào bảng “Post” ngăn cách nhau bằng dấu phẩy.
  • Bước 2: Sau khi em lấy ra được ra “Post” em cần, thì em lấy danh sách “Tag ID” ra rồi query để lấy thông tin “Tags”.

Lúc này trách được việc phải join, và lúc lấy thông tin “Tags” cũng query trên primary key (có index) nên sẽ nhanh hơn rất nhiều.

Thân,
Nguyễn Hữu Quyền

9 Likes
83% thành viên diễn đàn không hỏi bài tập, còn bạn thì sao?