Một cân nhắc quan trọng khi thiết kế lược đồ cho MongoDB không phải là dữ liệu của bạn là gì, mà là cách bạn sẽ sử dụng nó. Nếu không biết bạn sẽ thực hiện kiểu đọc và ghi nào (và hiệu suất của chúng như thế nào) thì rất khó để thiết kế một lược đồ "tối ưu".
Có một số hướng dẫn cơ bản mà bạn có thể xem xét để tránh gặp phải sự cố. Một trong số đó là tránh thiết kế các tài liệu liên tục phát triển không giới hạn. Điều đó có nghĩa là bạn không nên nhúng đơn đặt hàng vào tài liệu của khách hàng. Một quy tắc khác là những thứ không "quan tâm" (hoặc không tự tồn tại) có lẽ tốt hơn nên được nhúng vào. Điều này cho thấy rằng orderItems không xứng đáng với bộ sưu tập của riêng chúng và chỉ nên được coi là thuộc tính của đơn đặt hàng (thực tế là chúng là gì).
Bài tập chính xác này được đề cập trong khóa đào tạo dành cho nhà phát triển MongoDB, là một ví dụ khá điển hình về thiết kế lược đồ.
Điểm mấu chốt là bạn nên có ba bộ sưu tập:
Sản phẩm
Khách hàng
Đơn đặt hàng
Đơn đặt hàng sẽ tham chiếu đến khách hàng (tùy chọn không chuẩn hóa một số thông tin từ bộ sưu tập của khách hàng) và họ sẽ tham chiếu đến sản phẩm (trong mảng Đơn hàng mà họ sẽ chứa).
Các bộ sưu tập khác và các trường chính xác trong tất cả các bộ sưu tập này phụ thuộc vào trường hợp sử dụng cụ thể của bạn, nhưng tôi không thể thấy tình huống khả thi để có ít bộ sưu tập hơn ba bộ sưu tập này.
