Điều này có được coi là sai khi làm việc với cơ sở dữ liệu NoSQL không? Tôi có nên không suy nghĩ về 'quan hệ' khi làm việc với NoSQL không?
Có quá nhiều câu hỏi về trường hợp nhúng và quá ít.
Somethings chưa được đề cập ở đây mà cần phải được xem xét nếu bạn muốn nhúng:
- sẽ kích thước tài liệu được tăng ồ ạt? Nếu vậy thì tài liệu có thể thường xuyên di chuyển trên đĩa, đây là một điều xấu.
- Hàng có liên quan có nhiều lần tham gia vào bộ sưu tập mà tôi đang làm việc (ví dụ:
video không thể nhúng user). Nếu đây là trường hợp bạn có thể gặp sự cố khi sao chép dữ liệu dư thừa từ hàng có liên quan vào tài liệu phụ, đặc biệt là khi cập nhật dữ liệu dư thừa đó.
- Tôi sẽ cần hiển thị các kết quả này như thế nào?
Hiển thị kết quả luôn là quyết định quan trọng trong việc có nhúng hay không. Nếu bạn cần phân trang số hàng cao, giả sử 1000, bạn sẽ cần sử dụng toán tử $slice trong truy vấn thông thường hoặc khung tổng hợp. Tại 1000 tôi thừa nhận nó có thể là khá nhanh nhưng sớm hay muộn rằng hoạt động trong bộ nhớ sẽ trở nên chậm hơn so với truy vấn bình thường (infact nó luôn luôn nên được).
Nếu bạn cần phân loại phức tạp và hiển thị các tài liệu phụ, bạn có thể muốn chia này ra và thay vào đó có cấu trúc tài liệu của:
{
"string": "foobar",
"owners": [
ObjectId(),
ObjectId(),
ObjectId()
]
}
Tôi nghĩ rằng điều này thực sự có thể là một cấu trúc performant hơn anyway cho dữ liệu của bạn từ các âm thanh owner giống như một hàng user trong bộ sưu tập users.
Thay vì điền các tài liệu phụ có thể thay đổi dữ liệu của người dùng, bạn chỉ có thể tham khảo _id của họ. Đây là khá kool kể từ khi bạn có thể nhúng mối quan hệ nhưng đồng thời tài liệu sẽ chỉ phát triển rất ít hy vọng có nghĩa là một cơ hội thấp của chuyển động đĩa liên tục, không chỉ có vậy mà một bộ làm việc nhỏ hơn tạo ra một hoạt động hiệu quả hơn tổng thể. Không chỉ vậy nhưng tất nhiên, _id của chủ sở hữu hiếm khi thay đổi, do đó, các thao tác duy nhất bạn sẽ cần phải có nhiều khả năng nhất trong tập con dữ liệu này là tạo và xóa.
Quay lại phân loại và phân trang phức tạp. Với dữ liệu này, tất nhiên bạn có thể nhận được tất cả các id owner với một chuyến đi khứ hồi và sau đó trong một chuyến đi khứ hồi khác, bạn có thể truy vấn những hàng chủ sở hữu đó trong bảng users với truy vấn thông thường bằng cách sử dụng $in cho phép hiển thị phức tạp mà bạn yêu cầu.
Vì vậy, cấu trúc tổng thể này, tôi đã tìm thấy, rất hiệu quả. Tất nhiên cấu trúc này phụ thuộc vào truy vấn của bạn, có thể tốt hơn để thay thế id chuỗi trên người dùng nhưng trong trường hợp này, không phải vì người dùng có thể sở hữu nhiều chuỗi như vậy tôi sẽ nói nó là một nhiều-> nhiều mối quan hệ được nhúng vào bên chuỗi.
Hy vọng rằng điều này giúp và tôi đã không đi vòng vòng,
Vui lòng không sử dụng "NoSQL" làm ô. Bạn đang sử dụng MongoDB. Đó là nó."NoSQL" có nghĩa là * quá nhiều và quá ít * :-) –