Cách thiết kế lược đồ tài liệu ở MongoDB

Tác giả đã chọn Quỹ phát biểu trên Internet / miễn phí để nhận quyên góp như một phần của việc viết cho chương trình quyên góp.

Giới thiệu

Nếu bạn có nhiều kinh nghiệm làm việc với các cơ sở dữ liệu quan hệ, có thể khó vượt qua các nguyên tắc của mô hình quan hệ, chẳng hạn như suy nghĩ về các bảng và mối quan hệ. Các cơ sở dữ liệu định hướng tài liệu như MongoDB giúp có thể thoát khỏi độ cứng và hạn chế của mô hình quan hệ. Tuy nhiên, sự linh hoạt và tự do đi kèm với việc có thể lưu trữ các tài liệu tự mô tả trong cơ sở dữ liệu có thể dẫn đến các cạm bẫy và khó khăn khác.

Bài viết khái niệm này phác thảo năm hướng dẫn phổ biến liên quan đến thiết kế lược đồ trong cơ sở dữ liệu định hướng tài liệu và nhấn mạnh nhiều cân nhắc khác nhau mà người ta nên thực hiện khi mô hình hóa mối quan hệ giữa dữ liệu. Nó cũng sẽ đi bộ qua một số chiến lược, người ta có thể sử dụng để mô hình hóa các mối quan hệ như vậy, bao gồm cả các tài liệu nhúng trong mảng và sử dụng các tham chiếu trẻ em và cha mẹ, cũng như khi các chiến lược này sẽ phù hợp nhất để sử dụng.

Hướng dẫn 1 - Lưu trữ cùng những gì cần được truy cập cùng nhau

Trong cơ sở dữ liệu quan hệ điển hình, dữ liệu được giữ trong các bảng và mỗi bảng được xây dựng với một danh sách các cột cố định đại diện cho các thuộc tính khác nhau tạo nên một thực thể, đối tượng hoặc sự kiện. Ví dụ, trong một bảng đại diện cho sinh viên tại một trường đại học, bạn có thể tìm thấy các cột giữ tên, họ, ngày sinh của học sinh, ngày sinh và số nhận dạng duy nhất.

Thông thường, mỗi bảng đại diện cho một chủ đề duy nhất. Nếu bạn muốn lưu trữ thông tin về các nghiên cứu hiện tại, học bổng hoặc giáo dục trước đây của học sinh, có thể có ý nghĩa để giữ dữ liệu đó trong một bảng riêng biệt từ người giữ thông tin cá nhân của họ. Sau đó, bạn có thể kết nối các bảng này biểu thị rằng có một mối quan hệ giữa dữ liệu trong mỗi lần, cho biết thông tin chúng chứa có kết nối có ý nghĩa.

Chẳng hạn, một bảng mô tả trạng thái học bổng của mỗi học sinh có thể đề cập đến học sinh bằng số ID sinh viên của họ, nhưng nó sẽ không lưu trữ tên hoặc địa chỉ của học sinh trực tiếp, tránh sao chép dữ liệu. Trong trường hợp như vậy, để lấy thông tin về bất kỳ học sinh nào có tất cả thông tin về tài khoản phương tiện truyền thông xã hội của học sinh, giáo dục trước và học bổng, một truy vấn sẽ cần truy cập nhiều hơn một bảng tại một thời điểm và sau đó biên dịch kết quả từ các bảng khác nhau thành một .

Phương pháp mô tả các mối quan hệ này thông qua các tài liệu tham khảo được gọi là Mô hình dữ liệu chuẩn hóa . Lưu trữ dữ liệu theo cách này - Sử dụng nhiều đối tượng riêng biệt, ngắn gọn liên quan đến nhau - cũng có thể trong cơ sở dữ liệu định hướng tài liệu. Tuy nhiên, tính linh hoạt của mô hình tài liệu và sự tự do mà nó cung cấp để lưu trữ các tài liệu và mảng nhúng trong một tài liệu duy nhất có nghĩa là bạn có thể mô hình hóa dữ liệu khác với bạn có thể trong cơ sở dữ liệu quan hệ.

Khái niệm cơ bản để mô hình hóa dữ liệu trong cơ sở dữ liệu định hướng tài liệu là "lưu trữ cùng nhau những gì sẽ được truy cập cùng nhau." "Đào sâu vào ví dụ sinh viên, nói rằng hầu hết các sinh viên ở trường này có nhiều hơn một địa chỉ email. Bởi vì điều này, trường đại học muốn khả năng lưu trữ nhiều địa chỉ email với thông tin liên hệ của mỗi học sinh.

Trong một trường hợp như thế này, một tài liệu ví dụ có thể có cấu trúc như sau:

Đồn tin đồn { "_Id": ObjectID ["612D1E835EBEE16872A109A4"], "First_name": "Sammy", "Last_name": "Shark", "Email": [ Đồn tin đồn { "Email": "", "Loại": "Làm việc" }, Đồn tin đồn { "Email": "", "Loại": "Trang chủ" Không Có] Không

Lưu ý rằng tài liệu ví dụ này chứa một danh sách nhúng các địa chỉ email.

Đại diện nhiều hơn một chủ đề bên trong một tài liệu duy nhất đặc trưng cho DataMalized mô hình dữ liệu. Nó cho phép các ứng dụng truy xuất và thao tác tất cả các dữ liệu có liên quan cho một đối tượng nhất định [ở đây, một sinh viên] trong một lần mà không cần truy cập nhiều đối tượng và bộ sưu tập riêng biệt. Làm như vậy cũng đảm bảo tính nguyên tử của các hoạt động trên một tài liệu như vậy mà không phải sử dụng các giao dịch đa tài liệu để đảm bảo tính toàn vẹn.

Lưu trữ cùng nhau những gì cần được truy cập cùng nhau bằng cách sử dụng các tài liệu nhúng thường là cách tối ưu để thể hiện dữ liệu trong cơ sở dữ liệu định hướng tài liệu. Trong các hướng dẫn sau đây, bạn sẽ tìm hiểu cách các mối quan hệ khác nhau giữa các đối tượng, chẳng hạn như các mối quan hệ một-một hoặc một-nhiều, có thể được mô hình hóa tốt nhất trong cơ sở dữ liệu định hướng tài liệu.

Hướng dẫn 2 - Mô hình hóa mối quan hệ một-một với các tài liệu nhúng

A One-to-One Mối quan hệ đại diện cho sự liên kết giữa hai đối tượng riêng biệt trong đó một đối tượng được kết nối với chính xác một loại khác. < / a >.one-to-one relationship represents an association between two distinct objects where one object is connected with exactly one of another kind.

Tiếp tục với ví dụ sinh viên từ phần trước, mỗi sinh viên chỉ có một thẻ ID sinh viên hợp lệ tại bất kỳ thời điểm nào. Một thẻ không bao giờ thuộc về nhiều sinh viên và không có học sinh có thể có nhiều thẻ nhận dạng. Nếu bạn đã lưu trữ tất cả dữ liệu này trong một cơ sở dữ liệu quan hệ, nó có thể sẽ có ý nghĩa để mô hình hóa mối quan hệ giữa các sinh viên và thẻ ID của họ bằng cách lưu trữ các bản ghi sinh viên và các bản ghi chứng minh nhân dân trong các bảng riêng biệt được gắn với nhau thông qua các tài liệu tham khảo.

Một phương pháp phổ biến để thể hiện các mối quan hệ như vậy trong cơ sở dữ liệu tài liệu là bằng cách sử dụng các tài liệu nhúng. Ví dụ, tài liệu sau đây mô tả một học sinh có tên Sammy và thẻ ID sinh viên của họ:

Đồn tin đồn { "_Id": ObjectID ["612D1E835EBEE16872A109A4"], "First_name": "Sammy", "Last_name": "Shark", "id_card": { "Số": "123-1234-123", "Phát hành_on": isodate ["2020-01-23"], "expres_on": isodate ["2020-01-23"] Không Không

Lưu ý rằng thay vì một giá trị duy nhất, tài liệu ví dụ này id_card chứa một tài liệu nhúng đại diện cho thẻ nhận dạng của học sinh, được mô tả bởi một ID số, ngày của vấn đề và ngày hết hạn của thẻ. Chứng minh nhân dân về cơ bản trở thành một phần của tài liệu mô tả Sammy, mặc dù đó là một đối tượng riêng biệt trong cuộc sống thực. Thông thường, cấu trúc lược đồ tài liệu như thế này để bạn có thể truy xuất tất cả thông tin liên quan thông qua một truy vấn là một lựa chọn âm thanh. id_card field holds an embedded document representing the students identification card, described by an ID number, the cards date of issue, and the cards expiration date. The identity card essentially becomes a part of the document describing the student Sammy, even though its a separate object in real life. Usually, structuring the document schema like this so that you can retrieve all related information through a single query is a sound choice.

Mọi thứ trở nên ít đơn giản hơn nếu bạn gặp mối quan hệ kết nối một đối tượng của một vật thể với nhiều đối tượng thuộc loại khác, chẳng hạn như địa chỉ email của học sinh, các khóa học mà họ tham dự hoặc các tin nhắn họ đăng trên bảng tin của Hội đồng học sinh. Trong một vài hướng dẫn tiếp theo, bạn sẽ sử dụng các ví dụ dữ liệu này để tìm hiểu các phương pháp khác nhau để làm việc với các mối quan hệ một-nhiều và nhiều-nhiều-nhiều.

Hướng dẫn 3 - Mô hình hóa mối quan hệ một-một vài với các tài liệu nhúng

Khi một đối tượng của một loại có liên quan đến nhiều đối tượng của loại khác, nó có thể được mô tả là một-nhiều-nhiều Mối quan hệ . Một sinh viên có thể có nhiều địa chỉ email, một chiếc xe có thể có nhiều phần hoặc đơn đặt hàng mua sắm có thể bao gồm nhiều mặt hàng. Mỗi ví dụ này đại diện cho mối quan hệ một-nhiều. one-to-many relationship. A student can have multiple email addresses, a car can have numerous parts, or a shopping order can consist of multiple items. Each of these examples represents a one-to-many relationship.

Trong khi cách phổ biến nhất để thể hiện mối quan hệ một-một trong cơ sở dữ liệu tài liệu là thông qua một tài liệu nhúng, có một số cách để mô hình hóa các mối quan hệ một-nhiều trong một lược đồ tài liệu. Tuy nhiên, khi xem xét các tùy chọn của bạn để mô hình hóa tốt nhất, mặc dù, có ba thuộc tính của mối quan hệ đã cho bạn nên xem xét:

• Cardinality : Cardinality là thước đo số lượng các yếu tố riêng lẻ trong một bộ nhất định. Ví dụ: nếu một lớp có 30 sinh viên, bạn có thể nói rằng lớp học có một lá hồng cầu là 30. Trong một mối quan hệ một-nhiều, cardinality có thể khác nhau trong mỗi trường hợp. Một sinh viên có thể có một địa chỉ email hoặc nhiều. Họ có thể được đăng ký chỉ một vài lớp hoặc họ có thể có một lịch trình hoàn toàn đầy đủ. Trong một mối quan hệ một-nhiều, kích thước của "nhiều" sẽ ảnh hưởng đến cách bạn có thể mô hình hóa dữ liệu.
• Truy cập độc lập : Một số dữ liệu liên quan sẽ hiếm khi, nếu bao giờ, hãy truy cập riêng từ đối tượng chính. Ví dụ, có thể không phổ biến để lấy một địa chỉ email của một học sinh mà không cần các chi tiết sinh viên khác. Mặt khác, các khóa học của trường đại học có thể cần được truy cập và cập nhật riêng lẻ, bất kể học sinh hoặc học sinh được đăng ký tham dự họ. Cho dù bạn có bao giờ truy cập một tài liệu liên quan cũng sẽ ảnh hưởng đến cách bạn có thể mô hình hóa dữ liệu.
• Cho dù mối quan hệ giữa dữ liệu là một mối quan hệ một-nhiều : Hãy xem xét các khóa học một ví dụ học sinh tham dự tại một trường đại học. Từ quan điểm của học sinh, họ có thể tham gia nhiều khóa học. Trên bề mặt, đây có vẻ giống như một mối quan hệ một-nhiều. Tuy nhiên, các khóa học đại học hiếm khi có một học sinh tham dự; Thường xuyên hơn, nhiều sinh viên sẽ tham dự cùng một lớp. Trong trường hợp như thế này, mối quan hệ trong câu hỏi không thực sự là mối quan hệ một-nhiều, mà là một mối quan hệ nhiều-nhiều, và do đó bạn sẽ có một cách tiếp cận khác để mô hình hóa mối quan hệ này so với một người khác nhiều mối quan hệ.

Hãy tưởng tượng bạn đang quyết định cách lưu trữ địa chỉ email của sinh viên. Mỗi sinh viên có thể có nhiều địa chỉ email, chẳng hạn như một cho công việc, một cho sử dụng cá nhân và một địa chỉ được cung cấp bởi các trường đại học. Một tài liệu đại diện cho một địa chỉ email duy nhất có thể có một biểu mẫu như thế này:

Đồn tin đồn { "Email": "", "Loại": "Làm việc" Không

Xét về tính cardinality, sẽ chỉ có một vài địa chỉ email cho mỗi học sinh, vì không có khả năng học sinh sẽ có hàng chục - chứ đừng nói đến hàng trăm địa chỉ email. Do đó, mối quan hệ này có thể được đặc trưng là one-to-few relationship, which is a compelling reason to embed email addresses directly into the student document and store them together. You dont run any risk that the list of email addresses will grow indefinitely, which would make the document big and inefficient to use.

Về quyền truy cập độc lập, địa chỉ email có thể sẽ không được truy cập riêng từ học sinh. Như vậy, không có ưu đãi rõ ràng để lưu trữ chúng dưới dạng các tài liệu riêng biệt trong một bộ sưu tập riêng. Đây là một lý do hấp dẫn khác để nhúng chúng vào tài liệu của học sinh.

Điều cuối cùng cần xem xét là liệu mối quan hệ này thực sự là mối quan hệ một-nhiều thay vì một mối quan hệ nhiều-nhiều. Bởi vì một địa chỉ email thuộc về một người duy nhất, nó hợp lý để mô tả mối quan hệ này là mối quan hệ một-nhiều [hoặc, có lẽ chính xác hơn, một mối quan hệ một-một vài] thay vì một mối quan hệ nhiều-nhiều.

Ba giả định này cho thấy rằng nhúng các địa chỉ email khác nhau của học sinh trong cùng các tài liệu mô tả chính các sinh viên sẽ là một lựa chọn tốt để lưu trữ loại dữ liệu này. Tài liệu của học sinh mẫu với địa chỉ email được nhúng có thể lấy hình dạng này:

Đồn tin đồn { "_Id": ObjectID ["612D1E835EBEE16872A109A4"], "First_name": "Sammy", "Last_name": "Shark", "Email": [ Đồn tin đồn { "Email": "", "Loại": "Làm việc" }, Đồn tin đồn { "Email": "", "Loại": "Trang chủ" Không Có] Không

Sử dụng cấu trúc này, mỗi lần bạn truy xuất tài liệu của học sinh, bạn cũng sẽ truy xuất các địa chỉ email được nhúng trong cùng thao tác đọc.

Nếu bạn mô hình hóa mối quan hệ của nhiều thành số, trong đó các tài liệu liên quan không cần phải được truy cập độc lập, nhúng các tài liệu trực tiếp như thế này thường là mong muốn, vì điều này có thể làm giảm sự phức tạp của lược đồ.

Như đã đề cập trước đây, mặc dù, hãy nhúng các tài liệu như thế này không phải lúc nào cũng là giải pháp tối ưu. Phần tiếp theo cung cấp thêm chi tiết về lý do tại sao đây có thể là trường hợp trong một số kịch bản và phác thảo cách sử dụng các tài liệu tham khảo trẻ em như một cách khác để thể hiện các mối quan hệ trong cơ sở dữ liệu tài liệu.

Hướng dẫn 4 - Mô hình hóa mối quan hệ một-nhiều và nhiều-nhiều với các tài liệu tham khảo trẻ em

Bản chất của mối quan hệ giữa các sinh viên và địa chỉ email của họ đã thông báo về cách mối quan hệ đó có thể được mô hình hóa tốt nhất trong cơ sở dữ liệu tài liệu. Có một số khác biệt giữa điều này và mối quan hệ giữa các sinh viên và các khóa học mà họ tham dự, vì vậy cách bạn mô hình hóa mối quan hệ giữa các sinh viên và các khóa học của họ cũng sẽ khác nhau.

Một tài liệu mô tả một khóa học duy nhất mà một học sinh tham dự có thể theo dõi một cấu trúc như thế này:

Đồn tin đồn { "Tên": "Vật lý 101", "Bộ": "Cục Vật lý", "Điểm": 7 Không

Nói rằng bạn đã quyết định ngay từ đầu để sử dụng các tài liệu nhúng để lưu trữ thông tin về các khóa học của mỗi học sinh, như trong ví dụ này:

Đồn tin đồn { "_Id": ObjectID ["612D1E835EBEE16872A109A4"], "First_name": "Sammy", "Last_name": "Shark", "Email": [ Đồn tin đồn { "Email": "", "Loại": "Làm việc" }, Đồn tin đồn { "Email": "", "Loại": "Trang chủ" Không ], "Khóa học": [ Đồn tin đồn { "Tên": "Vật lý 101", "Bộ": "Cục Vật lý", "Điểm": 7 }, Đồn tin đồn { "Tên": "Giới thiệu về điện toán đám mây", "Bộ": "Khoa học máy tính", "Điểm": 4 Không Có] Không

Đây sẽ là một tài liệu MongoDB hoàn toàn hợp lệ và cũng có thể phục vụ mục đích, nhưng hãy xem xét ba thuộc tính mối quan hệ bạn đã học về hướng dẫn trước đó.

Cái đầu tiên là Cardinality. Một học sinh có thể sẽ chỉ duy trì một vài địa chỉ email, nhưng họ có thể tham dự nhiều khóa học trong quá trình học tập. Sau vài năm tham dự, có thể có hàng chục khóa học, học sinh đã tham gia. Thêm vào đó, họ sẽ tham dự các khóa học này cùng với nhiều sinh viên khác, những học sinh khác cũng tham dự tập hợp các khóa học của riêng họ trong những năm tham dự của họ.

Nếu bạn quyết định nhúng từng khóa học như ví dụ trước, tài liệu của học sinh sẽ nhanh chóng có được khó sử dụng. Với một kho chứa cao hơn, cách tiếp cận tài liệu nhúng trở nên ít hấp dẫn hơn.

Việc xem xét thứ hai là quyền truy cập độc lập. Không giống như địa chỉ email, nghe có vẻ giả định sẽ có những trường hợp trong đó thông tin về các khóa học đại học sẽ cần phải được truy xuất một mình. Chẳng hạn, hãy nói ai đó cần thông tin về các khóa học có sẵn để chuẩn bị một tập tài liệu tiếp thị. Ngoài ra, các khóa học có thể sẽ cần phải được cập nhật theo thời gian: Giáo sư giảng dạy khóa học có thể thay đổi, lịch trình của nó có thể dao động hoặc điều kiện tiên quyết của nó có thể cần phải được cập nhật.

Nếu bạn đã lưu trữ các khóa học như các tài liệu được nhúng trong tài liệu của học sinh, hãy truy xuất danh sách tất cả các khóa học do trường đại học cung cấp sẽ trở nên rắc rối. Ngoài ra, mỗi lần một khóa học cần một bản cập nhật, bạn sẽ cần phải trải qua tất cả các hồ sơ của học sinh và cập nhật thông tin khóa học ở mọi nơi. Cả hai đều là những lý do tốt để lưu trữ các khóa học riêng biệt và không nhúng chúng đầy đủ.

Điều thứ ba cần xem xét là liệu mối quan hệ giữa sinh viên và một khóa học đại học thực sự là một-nhiều hay thay vào đó nhiều-nhiều. Trong trường hợp này, đó là cái sau, vì nhiều sinh viên có thể tham dự mỗi khóa học. Các khía cạnh của mối quan hệ và các khía cạnh truy cập độc lập này cho thấy việc nhúng từng tài liệu khóa học, chủ yếu vì những lý do thực tế như dễ dàng truy cập và cập nhật. Xem xét nhiều yếu tố nhiều với mối quan hệ giữa các khóa học và sinh viên, nó có thể có ý nghĩa để lưu trữ các tài liệu khóa học trong một bộ sưu tập riêng với các định danh duy nhất của riêng họ.

Các tài liệu đại diện cho các lớp trong bộ sưu tập riêng biệt này có thể có cấu trúc như những ví dụ sau:

Đồn tin đồn { "_Id": ObjectID ["61741c9cbc9ec583c836170A"], "Tên": "Vật lý 101", "Bộ": "Cục Vật lý", "Điểm": 7 }, Đồn tin đồn { "_Id": ObjectID ["61741c9cbc9ec583c836170b"], "Tên": "Giới thiệu về điện toán đám mây", "Bộ": "Khoa học máy tính", "Điểm": 4 Không

Nếu bạn quyết định lưu trữ thông tin khóa học như thế này, bạn sẽ cần tìm cách kết nối sinh viên với các khóa học này để bạn biết những học sinh nào tham dự các khóa học nào. Trong trường hợp như thế này, số lượng các đối tượng liên quan không quá lớn, đặc biệt là với nhiều mối quan hệ nhiều-nhiều, một cách phổ biến để làm điều này là sử dụng child references.

Với tài liệu tham khảo trẻ em, tài liệu của học sinh sẽ tham chiếu các định danh đối tượng của các khóa học mà học sinh tham dự trong một mảng nhúng, như trong ví dụ này:

Đồn tin đồn { "_Id": ObjectID ["612D1E835EBEE16872A109A4"], "First_name": "Sammy", "Last_name": "Shark", "Email": [ Đồn tin đồn { "Email": "", "Loại": "Làm việc" }, Đồn tin đồn { "Email": "", "Loại": "Trang chủ" Không ], "Khóa học": [ ObjectID ["61741c9cbc9ec583c836170A"], ObjectID ["61741c9cbc9ec583c836170b"] Có] Không

Lưu ý rằng tài liệu ví dụ này vẫn có các khóa học cũng là một mảng, nhưng thay vì nhúng các tài liệu khóa học đầy đủ như trước Ví dụ, chỉ các định danh tham chiếu các tài liệu khóa học trong bộ sưu tập riêng biệt được nhúng. Bây giờ, khi lấy một tài liệu sinh viên, các khóa học sẽ không có sẵn ngay lập tức và sẽ cần được truy vấn riêng. Mặt khác, nó ngay lập tức được biết đến những khóa học để lấy. Ngoài ra, trong trường hợp bất kỳ chi tiết nào của khóa học cần được cập nhật, chỉ có tài liệu khóa học cần phải được thay đổi. Tất cả các tài liệu tham khảo giữa các sinh viên và các khóa học của họ sẽ vẫn hợp lệ. courses field which also is an array, but instead of embedding full course documents like in the earlier example, only the identifiers referencing the course documents in the separate collection are embedded. Now, when retrieving a student document, courses will not be immediately available and will need to be queried separately. On the other hand, its immediately known which courses to retrieve. Also, in case any courses details need to be updated, only the course document itself needs to be altered. All references between students and their courses will remain valid.

LƯU Ý: Không có quy tắc vững chắc khi cardinality của mối quan hệ là quá lớn để nhúng các tài liệu tham khảo trẻ em theo cách này. Bạn có thể chọn một cách tiếp cận khác với Cardinality thấp hơn hoặc cao hơn nếu đó là những gì phù hợp nhất với ứng dụng trong câu hỏi. Rốt cuộc, bạn sẽ luôn muốn cấu trúc dữ liệu của mình phù hợp với cách thức mà ứng dụng của bạn truy vấn và cập nhật nó.

Nếu bạn mô hình hóa mối quan hệ một-nhiều trong đó số lượng tài liệu liên quan nằm trong giới hạn hợp lý và các tài liệu liên quan cần được truy cập độc lập, ưu tiên lưu trữ các tài liệu liên quan riêng biệt và nhúng các tài liệu tham khảo trẻ em để kết nối với chúng.

Bây giờ bạn đã học cách sử dụng các tài liệu tham khảo trẻ em để biểu thị mối quan hệ giữa các loại dữ liệu khác nhau, hướng dẫn này sẽ phác thảo một khái niệm nghịch đảo: Tài liệu tham khảo cha mẹ.

Hướng dẫn 5 - Mô hình hóa mối quan hệ một-một-nhiều không giới hạn với các tài liệu tham khảo cha mẹ

Sử dụng các tài liệu tham khảo trẻ em hoạt động tốt khi có quá nhiều đối tượng liên quan để nhúng chúng trực tiếp vào tài liệu cha mẹ, nhưng số tiền vẫn nằm trong giới hạn đã biết. Tuy nhiên, có những trường hợp khi số lượng tài liệu liên quan có thể bị hủy và sẽ tiếp tục phát triển theo thời gian.

Ví dụ, hãy tưởng tượng rằng Hội đồng sinh viên của trường đại học có một bảng tin nơi bất kỳ học sinh nào có thể đăng bất cứ tin nhắn nào họ muốn, bao gồm các câu hỏi về các khóa học, câu chuyện du lịch, bài đăng công việc, tài liệu học tập hoặc chỉ là một cuộc trò chuyện miễn phí. Một thông báo mẫu trong ví dụ này bao gồm một chủ đề và một cơ quan thông báo:

Đồn tin đồn { "_ID": ObjectID ["61741c9cbc9ec583c836174c"], "Chủ đề": "Sách về động học và động lực", "Tin nhắn": "Xin chào! Bạn có thể giới thiệu những cuốn sách giới thiệu tốt bao gồm các chủ đề của động học và động lực? Cảm ơn!", "Đăng_on": isodate ["2021-07-23T16: 03: 21z"] Không

Bạn có thể sử dụng một trong hai cách tiếp cận đã thảo luận trước đây - nhúng và tài liệu tham khảo trẻ em - để mô hình hóa mối quan hệ này. Nếu bạn quyết định nhúng nhúng, tài liệu của học sinh có thể có một hình dạng như thế này:

Đồn tin đồn { "_Id": ObjectID ["612D1E835EBEE16872A109A4"], "First_name": "Sammy", "Last_name": "Shark", "Email": [ Đồn tin đồn { "Email": "", "Loại": "Làm việc" }, Đồn tin đồn { "Email": "", "Loại": "Trang chủ" Không ], "Khóa học": [ ObjectID ["61741c9cbc9ec583c836170A"], ObjectID ["61741c9cbc9ec583c836170b"] ], "message_board_messages": [ Đồn tin đồn { "Chủ đề": "Sách về động học và động lực", "Tin nhắn": "Xin chào! Bạn có thể giới thiệu những cuốn sách giới thiệu tốt bao gồm các chủ đề của động học và động lực? Cảm ơn!", "Đăng_on": isodate ["2021-07-23T16: 03: 21z"] }, . . . Có] Không

Tuy nhiên, nếu một học sinh sung mãn với việc viết tin nhắn tài liệu của họ sẽ nhanh chóng trở nên cực kỳ dài và có thể dễ dàng vượt quá giới hạn kích thước 16 MB, do đó Cardinality của mối quan hệ này cho thấy sự nhúng. Ngoài ra, các tin nhắn có thể cần phải được truy cập riêng biệt với học sinh, như trường hợp nếu trang bảng tin được thiết kế để hiển thị các tin nhắn mới nhất được đăng bởi các sinh viên. Điều này cũng gợi ý rằng nhúng không phải là sự lựa chọn tốt nhất cho kịch bản này.

Lưu ý: Bạn cũng nên xem xét liệu các tin nhắn bảng thông báo có được truy cập thường xuyên khi lấy tài liệu của học sinh hay không khi lấy tài liệu của học sinh. Nếu không, việc tất cả chúng được nhúng trong tài liệu đó sẽ phải chịu một hình phạt hiệu suất khi truy xuất và thao tác tài liệu này, ngay cả khi danh sách tin nhắn sẽ không được sử dụng thường xuyên. Truy cập không thường xuyên của dữ liệu liên quan thường là một manh mối khác mà bạn không nên nhúng các tài liệu.

Bây giờ hãy xem xét sử dụng các tài liệu tham khảo trẻ em thay vì nhúng các tài liệu đầy đủ như trong ví dụ trước. Các tin nhắn riêng lẻ sẽ được lưu trữ trong một bộ sưu tập riêng biệt và tài liệu của học sinh sau đó có thể có cấu trúc sau:

Đồn tin đồn { "_Id": ObjectID ["612D1E835EBEE16872A109A4"], "First_name": "Sammy", "Last_name": "Shark", "Email": [ Đồn tin đồn { "Email": "", "Loại": "Làm việc" }, Đồn tin đồn { "Email": "", "Loại": "Trang chủ" Không ], "Khóa học": [ ObjectID ["61741c9cbc9ec583c836170A"], ObjectID ["61741c9cbc9ec583c836170b"] ], "message_board_messages": [ ObjectID ["61741c9cbc9ec583c836174c"], . . . Có] Không

Trong ví dụ này, message_board_messages Hiện lưu trữ các tài liệu tham khảo trẻ em đến tất cả các tin nhắn được viết bởi Sammy. Tuy nhiên, việc thay đổi cách tiếp cận chỉ giải quyết một trong những vấn đề được đề cập trước đó, bây giờ có thể truy cập các thông báo một cách độc lập. Nhưng mặc dù kích thước tài liệu của học sinh sẽ phát triển chậm hơn khi sử dụng phương pháp tham chiếu trẻ em, việc thu thập các định danh đối tượng cũng có thể trở nên khó sử dụng với tính cardinality không giới hạn của mối quan hệ này. Một sinh viên có thể dễ dàng viết hàng ngàn tin nhắn trong bốn năm học của họ, sau tất cả.

Trong các trường hợp như vậy, một cách phổ biến để kết nối một đối tượng với một đối tượng khác là thông qua Tài liệu tham khảo phụ huynh . Không giống như các tài liệu tham khảo trẻ em được mô tả trước đây, giờ đây không phải là tài liệu sinh viên đề cập đến các tin nhắn riêng lẻ, mà là một tài liệu tham khảo trong tài liệu của tin nhắn hướng về học sinh đã viết nó.

Để sử dụng các tài liệu tham khảo phụ huynh, bạn sẽ cần sửa đổi lược đồ tài liệu tin nhắn để chứa một tham chiếu đến học sinh đã tác giả tin nhắn:

Đồn tin đồn { "_ID": ObjectID ["61741c9cbc9ec583c836174c"], "Chủ đề": "Sách về động học và động lực", "Tin nhắn": "Xin chào! Bạn có thể giới thiệu một cuốn sách giới thiệu tốt bao gồm các chủ đề của động học và động lực? Cảm ơn!", "Đăng_on": isodate ["2021-07-23T16: 03: 21z"], "Đăng_by": ObjectID ["612D1E835EBEE16872A109A4"] Không

Thông báo mới Đăng_by Trường chứa định danh đối tượng của tài liệu của học sinh. Bây giờ, tài liệu của học sinh sẽ không chứa bất kỳ thông tin nào về các tin nhắn họ đã đăng:

Đồn tin đồn { "_Id": ObjectID ["612D1E835EBEE16872A109A4"], "First_name": "Sammy", "Last_name": "Shark", "Email": [ Đồn tin đồn { "Email": "", "Loại": "Làm việc" }, Đồn tin đồn { "Email": "", "Loại": "Trang chủ" Không ], "Khóa học": [ ObjectID ["61741c9cbc9ec583c836170A"], ObjectID ["61741c9cbc9ec583c836170b"] Có] Không

Để lấy danh sách các tin nhắn được viết bởi một sinh viên, bạn sẽ sử dụng truy vấn trên bộ sưu tập tin nhắn và bộ lọc so với Đăng_by . Có chúng trong một bộ sưu tập riêng biệt giúp việc để danh sách tin nhắn phát triển mà không ảnh hưởng đến bất kỳ tài liệu nào của học sinh.

LƯU Ý: Khi sử dụng các tài liệu tham khảo cha, tạo một chỉ mục trên trường tham chiếu Tài liệu cha có thể tăng đáng kể hiệu suất truy vấn mỗi khi bạn lọc so với định danh tài liệu cha. . When using parent references, creating an index on the field referencing the parent document can significantly increase the query performance each time you filter against the parent document identifier.

Nếu bạn mô hình hóa một mối quan hệ một-nhiều trong đó số lượng tài liệu liên quan không bị ràng buộc, bất kể các tài liệu nào cần phải được truy cập độc lập, thường khuyên bạn nên lưu trữ các tài liệu liên quan riêng biệt và sử dụng các tham chiếu phụ huynh để kết nối chúng với tài liệu phụ huynh .

Phần kết luận

Nhờ tính linh hoạt của các cơ sở dữ liệu định hướng tài liệu, xác định cách tốt nhất để mô hình hóa các mối quan hệ trong một cơ sở dữ liệu tài liệu ít hơn một khoa học nghiêm ngặt hơn là trong cơ sở dữ liệu quan hệ. Bằng cách đọc bài viết này, bạn đã làm quen với chính mình với các tài liệu nhúng và sử dụng các tham chiếu trẻ em và cha mẹ để lưu trữ dữ liệu liên quan. Bạn đã học về việc xem xét sự ghi nhớ mối quan hệ và tránh các mảng không giới hạn, cũng như có tính đến liệu tài liệu sẽ được truy cập riêng hoặc thường xuyên.

Đây chỉ là một vài hướng dẫn có thể giúp bạn mô hình hóa các mối quan hệ điển hình trong MongoDB, nhưng lược đồ cơ sở dữ liệu mô hình hóa không phải là một kích thước phù hợp với tất cả. Luôn luôn tính đến ứng dụng của bạn và cách sử dụng và cập nhật dữ liệu khi thiết kế lược đồ.

Để tìm hiểu thêm về thiết kế lược đồ và các mẫu thông thường để lưu trữ các loại dữ liệu khác nhau ở MongoDB, chúng tôi khuyến khích bạn kiểm tra tài liệu MongoDB chính thức về chủ đề đó.