Ví dụ bạn đưa ra, giống với hầu hết các ví dụ trong thế giới thực về mối quan hệ nhiều-nhiều, thực sự là một ví dụ về vài-vài mối quan hệ. Bạn có thể có nhiều nhà hàng và nhiều thực khách, nhưng so với toàn bộ tập hợp, bất kỳ nhà hàng nhất định nào cũng chỉ phục vụ một nhóm nhỏ thực khách và hầu hết thực khách riêng lẻ sẽ chỉ ghé thăm một nhóm nhỏ trong số các nhà hàng. Nó có vẻ giống như một mạng được liên kết thưa thớt trong đó tỷ lệ mật độ liên kết thấp hơn đáng kể.
Tuy nhiên, bạn đã hỏi về nhiều-nhiều, vậy chúng ta sử dụng mạng nơ-ron làm ví dụ như thế nào? Mạng nơ-ron thường tạo thành mạng dày đặc và do đó đại diện cho một mạng nhiều-nhiều thực sự. Trong trường hợp đó, câu trả lời là dễ dàng - không sử dụng mongoDB. Sử dụng cấu trúc tùy chỉnh và chiến lược tuần tự hóa phù hợp với yêu cầu cụ thể của bạn. Rốt cuộc, các mối quan hệ giữa nhiều người thực sự gần như luôn luôn là ngoại lệ và do đó, biện minh cho việc điều trị cụ thể.
Như đã nói, việc lập mô hình ít đến một số thông thường hơn Mối quan hệ trong mongoDB có thể đạt được mà không phải hy sinh cấu trúc tài liệu phong phú và cách bạn đạt được điều này phụ thuộc vào các mẫu truy cập của bạn.
Vì vậy, với ví dụ về mạng nhà hàng / quán ăn, nếu bạn thường truy vấn một nhà hàng về thực khách của nhà hàng đó thì bạn sẽ tạo một mảng diner_ids được tổ chức với mỗi nhà hàng. Theo cách khác, có nghĩa là một loạt các nhà hàng được tổ chức với mỗi quán ăn. Cả hai đều cho khả năng truy vấn hai chiều.
Cần phải cẩn thận vì không có ràng buộc khóa ngoại trong mongoDB và do đó, việc duy trì tính toàn vẹn tham chiếu của dữ liệu là trách nhiệm của bạn.
Nếu hiệu suất là quan trọng nhất đối với bạn thì bạn có thể muốn nhúng dữ liệu vào mỗi tài liệu hơn là tham chiếu nó với một id. Đây là tùy chọn hiệu suất cao hơn để đọc (không quá nhiều để ghi) vì tất cả dữ liệu có thể được lấy ra khỏi đĩa trong một lần truy cập. Có nghĩa là bạn sẽ cần phải thực hiện nhiều công việc hơn khi cập nhật các giá trị dữ liệu để đảm bảo tính toàn vẹn của dữ liệu, nhưng thường thì điều này không đáng sợ như lúc đầu. Các thực khách thường thay đổi tên của họ bao lâu một lần? Và tùy thuộc vào kích thước tài liệu, bạn có thể không nhất thiết phải nhúng tài liệu đầy đủ, một tập hợp con dữ liệu cộng với một id để trỏ đến bản ghi đầy đủ thường sẽ thực hiện thủ thuật.
Tóm lại, thiết kế lược đồ mongoDB nên được thúc đẩy bởi các yêu cầu ứng dụng. Các lược đồ khác nhau cho các ứng dụng khác nhau trái ngược với một DB quan hệ đơn nguyên để thống trị tất cả chúng. Thực tế của dữ liệu là gì? Ứng dụng thực sự sử dụng dữ liệu này như thế nào? Các đối tượng tài liệu đang được lưu trữ lớn đến mức nào? Trả lời những câu hỏi này và lược đồ của bạn thực tế sẽ tự thiết kế.
