Thiết kế lược đồ cơ sở dữ liệu Mongodb với dữ liệu được chia sẻ

Thách thức của bạn đến từ thực tế là Prop_Info phải được truy xuất bởi cả hai truy vấn. Điều này gây khó khăn cho việc tìm ra bộ sưu tập Mongo nào mà nó sẽ có trong đó.

Trong MongoDB, bạn tạo lược đồ tài liệu của mình với mục tiêu lý tưởng cho một tài liệu duy nhất có tất cả thông tin bạn cần cho các mẫu truy vấn của bạn. Trong trường hợp bạn cần có cùng một dữ liệu D (chẳng hạn như Prop_Info trong trường hợp của bạn) được trả về bởi hai truy vấn riêng biệt so với hai tập hợp riêng biệt A và B , bạn phải chọn giữa ba chiến lược sau:

1. Sao y D trong các tài liệu của cả A và B và thực thi tính nhất quán với mã của bạn. Đây thường là lựa chọn thiết kế của các hệ thống hiệu suất cao muốn loại bỏ nhu cầu truy vấn thứ hai ngay cả khi điều đó phải trả giá bằng sự phức tạp của mã bổ sung ở phía chèn / cập nhật và với một số vấn đề nhất quán tiềm ẩn vì Mongo không phải là ACID.

2. Đặt D trong A và lưu trữ một tham chiếu (DBRef hoặc một số kết hợp nhận dạng trường khác) trong B để bạn có thể truy cập nó bằng một truy vấn thứ hai. Đây thường là lựa chọn thiết kế khi số lượng truy vấn đến A vượt quá số lượng truy vấn đến B . Nó giữ D cục bộ cho bộ sưu tập được truy vấn thường xuyên hơn. Trong mẫu thiết kế giản đồ này, bạn chỉ cần thực hiện truy vấn thứ hai khi truy vấn B .

3. Đặt D trong bộ sưu tập mới C và thực hiện truy vấn thứ hai cho nó từ cả A và B . Đây thường là sự lựa chọn thiết kế khi đối mặt với các yêu cầu rất không chắc chắn trong tương lai, trong đó không rõ sự đánh đổi sẽ là gì nếu bạn đi với (1) hoặc (2) ở trên. Đây là lược đồ "giống quan hệ" nhất và sẽ buộc bạn thực hiện truy vấn thứ hai khi bạn truy vấn cả A và B .

Bạn chọn chiến lược nào phụ thuộc vào miền của bạn, các mẫu truy vấn, sự hỗ trợ bạn nhận được từ khuôn khổ ánh xạ quan hệ đối tượng (ORM) (nếu bạn sử dụng) và cuối cùng nhưng không kém phần quan trọng, tùy chọn của bạn.

Trong những tình huống tôi gặp phải, tôi chưa bao giờ lựa chọn (3). Tôi đã sử dụng (1) trong các tình huống hiệu suất cao (hệ thống phân tích). Tôi đã sử dụng (2) ở mọi nơi khác vì các mẫu truy cập truy vấn đã cho thấy rõ nơi dữ liệu "được chia sẻ" sẽ nằm ở đâu.

Khi bạn chọn chiến lược của mình, nếu bạn vẫn cần hỗ trợ, hãy đăng một câu hỏi SO khác tập trung cụ thể vào vấn đề thiết kế lược đồ với chiến lược đã chọn.

Ba mẹo cuối cùng:

1. Nếu dữ liệu được chia sẻ D có một quan hệ bội số lớn hơn 1 sử dụng một mảng. Bạn có thể lập chỉ mục toàn bộ mảng và bạn có thể truy vấn chính xác bên trong mảng bằng cách sử dụng $elemMatch .

2. Để cập nhật D trong chiến lược (1) hoặc (2) sử dụng công cụ sửa đổi nguyên tử của MongoDB hoạt động , nhiều trong số đó được thiết kế để hoạt động trên mảng.

3. Câu hỏi SO này bao gồm mẫu truy vấn DBRef hai trong câu trả lời của @ Stennie. (@Stennie làm việc cho 10gen, điểm đánh dấu của MongoDB.)

Chúc may mắn!