Đối tượng trả về với các bảng liên kết n-n trong dự án thực tế

#1

Chào mọi người, trong quá trình làm dự án cá nhân thì em có vướng mắc một số vấn đề. Ở đây em có một bảng Book và nó liên kết nhiều nhiều với bảng Tag. Em đang có 2 hướng là nhét tag vào trong book khi trả api về luôn hoặc chỉ trả book thôi, xong front-end lấy id của book ra gọi api lấy tag.

Thì ở đây em có thắc mắc là trong các dự án thực tế, với các liên kết nhiều nhiều như vậy, họ hay làm theo cách nào? Nếu mang tính tương đối (cả 2 cách đều được áp dụng phổ biến) thì trong những trường hợp nào sẽ chọn cách nào?

#2

IMO có thể làm cả 2 phụ thuộc vào “view”. Nếu book mà có ít tags thì trả về luôn, nhiều thì vẫn có thể trả về TOP 5 tags của book đó chẳng hạn, khi cần lấy hết thì có api tags theo book_id.

#3

Trong thực tế, khi ra mô hình CSDL thì không còn tồn tại liên kết nhiều-nhiều. Giữa 2 bảng BOOK và TAG sẽ có một bảng trung gian, vd như TagOfBook, trong đó quan hệ giữa BOOK và TagOfBook là một-nhiểu, giữa TAG và TagOfBook cũng là liên kết một-nhiều.

Thắc mắc là bạn có học môn CSDL hoặc Phân Tích Thiết Kế trong chương trình học ko ?

3 Likes
#4

Em biết là khi liên kết nhiều - nhiều xảy ra thì trong cơ sở dữ liệu sẽ phải sinh thêm bảng con, và trong chương trình học cũng đề cập. Cụm từ nhiều - nhiều cũng không phải cái gì em phát minh ra và trong chương trình học cũng có nói đến nó thì em xài nhiều-nhiều có gì sai ạ? Nó cũng chỉ là cách mô tả hay là anh thích em phải nói là bảng Book liên kết một nhiều với bảng phụ và bảng Tag cũng liên kết một nhiều với bảng phụ? Chả hiểu sao anh phản phản ứng kiểu vậy luôn?

1 Like
#5

Bảng = Table, khác với Entity ở mô hình ERD. Khi nói tới table nghĩa là nói tới mô hình CSDL quan hệ, ở mức này thì không-còn quan hệ nhiều nhiều, trừ khi cố tình phi chuẩn vì một mục đích nào đó. Cho nên khi bạn nói 2 bảng Book và Tag quan hệ nhiều nhiều là đã sai.

#6

vâng, cái này thì là do em dùng từ sai, lần sau em sẽ rút kinh nghiệm

1 Like
#7

Chẳng việc gì phải rút kinh nghiệm trong trường hợp này cả, anh trên rõ là bắt bẻ câu từ hơn là góp ý.

#8

Thường thì trong thực tế, trả về full model (bao gồm cả book và tag) sẽ thường được sử dụng hơn. Lý do vì nó đơn giản hơn cho tất cả các bên.

  • Thêm 1 API lấy tag từ book ID sẽ khiến xử lý thêm phức tạp. Cậu sẽ phải lo xử lý chuyện gì nếu API đó fail, hoặc trả về dữ liệu không như kỳ vọng.
  • Về phía backend, tự dưng phải maintain thêm 1 API, trong khi tag buộc phải nằm trong model Book.
  • Nếu trong TH bên consumer không cần dữ liệu tag, bên backend có thể support cung cấp parameter để bỏ những dữ liệu không cần thiết.

Trừ khi cậu có lý do gì đặc biệt lắm (mà tớ chưa nghĩ ra :smile:), cậu mới làm cách tạo thêm 1 API nữa để lấy tag từ book ID.

5 Likes
#9

nếu tag list lớn cần paginate thì vẫn cần 1 API mới.

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