Lược đồ mẫu MongoDB

Dữ liệu trong MongoDB có lược đồ linh hoạt. tài liệu trong cùng một bộ sưu tập. Chúng không cần phải có cùng một nhóm trường hoặc cấu trúc Các trường chung trong tài liệu của một bộ sưu tập có thể chứa các loại dữ liệu khác nhau

Nội dung chính Show

Thiết kế mô hình dữ liệu
Mô hình dữ liệu nhúng
Mô hình dữ liệu chuẩn hóa
Những lưu ý khi thiết kế Schema trong MongoDB
Bạn có thể tạo một lược đồ trong MongoDB không?
Lược đồ MongoDB là gì?
Tôi có thể tìm lược đồ MongoDB ở đâu?
Lược đồ MongoDB có miễn phí không?

Thiết kế mô hình dữ liệu

MongoDB cung cấp hai loại mô hình dữ liệu. — Mô hình dữ liệu nhúng và mô hình dữ liệu chuẩn hóa. Dựa trên yêu cầu, bạn có thể sử dụng một trong hai mô hình trong khi chuẩn bị tài liệu của mình

Mô hình dữ liệu nhúng

Trong mô hình này, bạn có thể có (nhúng) tất cả dữ liệu liên quan vào một tài liệu duy nhất, nó còn được gọi là mô hình dữ liệu không chuẩn hóa

Ví dụ: giả sử chúng ta đang lấy thông tin chi tiết về nhân viên trong ba tài liệu khác nhau là Personal_details, Contact và Address, bạn có thể nhúng cả ba tài liệu vào một tài liệu duy nhất như hình bên dưới -

{
	_id: ,
	Emp_ID: "10025AE336"
	Personal_details:{
		First_Name: "Radhika",
		Last_Name: "Sharma",
		Date_Of_Birth: "1995-09-26"
	},
	Contact: {
		e-mail: "[email protected]",
		phone: "9848022338"
	},
	Address: {
		city: "Hyderabad",
		Area: "Madapur",
		State: "Telangana"
	}
}

Mô hình dữ liệu chuẩn hóa

Trong mô hình này, bạn có thể tham khảo các tài liệu phụ trong tài liệu gốc, sử dụng tài liệu tham khảo. Ví dụ: bạn có thể viết lại tài liệu trên theo mô hình chuẩn hóa dưới dạng

Nhân viên

{
	_id: ,
	Emp_ID: "10025AE336"
}

Thông tin cá nhân

{
	_id: ,
	empDocID: " ObjectId101",
	First_Name: "Radhika",
	Last_Name: "Sharma",
	Date_Of_Birth: "1995-09-26"
}

Tiếp xúc

{
	_id: ,
	empDocID: " ObjectId101",
	e-mail: "[email protected]",
	phone: "9848022338"
}

Địa chỉ nhà

{
	_id: ,
	empDocID: " ObjectId101",
	city: "Hyderabad",
	Area: "Madapur",
	State: "Telangana"
}

Những lưu ý khi thiết kế Schema trong MongoDB

Thiết kế lược đồ của bạn theo yêu cầu của người dùng
Kết hợp các đối tượng vào một tài liệu nếu bạn sẽ sử dụng chúng cùng nhau. Mặt khác, hãy tách chúng ra (nhưng đảm bảo rằng không cần tham gia)
Sao chép dữ liệu (nhưng có giới hạn) vì dung lượng đĩa rẻ so với thời gian tính toán
Tham gia trong khi viết, không đọc
Tối ưu hóa lược đồ của bạn cho hầu hết các trường hợp sử dụng thường xuyên
Thực hiện tổng hợp phức tạp trong lược đồ

Thí dụ

Giả sử một khách hàng cần thiết kế cơ sở dữ liệu cho blog/trang web của mình và xem sự khác biệt giữa thiết kế lược đồ RDBMS và MongoDB. Website có các yêu cầu sau

Mỗi bài đăng có tiêu đề, mô tả và url duy nhất
Mỗi bài đăng có thể có một hoặc nhiều thẻ
Mỗi bài đăng có tên của nhà xuất bản và tổng số lượt thích
Mỗi bài đăng đều có nhận xét của người dùng cùng với tên, tin nhắn, thời gian dữ liệu và lượt thích của họ
Trên mỗi bài đăng, có thể có 0 hoặc nhiều bình luận

Trong lược đồ RDBMS, thiết kế cho các yêu cầu trên sẽ có tối thiểu ba bảng

Trong lược đồ MongoDB, thiết kế sẽ có một bài đăng bộ sưu tập và cấu trúc sau -

{
   _id: POST_ID
   title: TITLE_OF_POST, 
   description: POST_DESCRIPTION,
   by: POST_BY,
   url: URL_OF_POST,
   tags: [TAG1, TAG2, TAG3],
   likes: TOTAL_LIKES, 
   comments: [	
      {
         user:'COMMENT_BY',
         message: TEXT,
         dateCreated: DATE_TIME,
         like: LIKES 
      },
      {
         user:'COMMENT_BY',
         message: TEXT,
         dateCreated: DATE_TIME,
         like: LIKES
      }
   ]
}

Vì vậy, trong khi hiển thị dữ liệu, trong RDBMS, bạn cần nối ba bảng và trong MongoDB, dữ liệu sẽ chỉ được hiển thị từ một bộ sưu tập

Có một cách lý tưởng để thiết kế cơ sở dữ liệu trong cơ sở dữ liệu quan hệ — dạng chuẩn thứ 3. Trong

{
	_id: ,
	empDocID: " ObjectId101",
	city: "Hyderabad",
	Area: "Madapur",
	State: "Telangana"
}

7, điều quan trọng là phải giữ dữ liệu theo cách có lợi cho ứng dụng sử dụng dữ liệu. Bạn nghĩ về

mẫu dữ liệu ứng dụng
những phần dữ liệu nào được sử dụng cùng nhau
phần dữ liệu nào được sử dụng chủ yếu ở dạng chỉ đọc
những phần dữ liệu nào được viết mọi lúc

Ngược lại, trong DBMS quan hệ — dữ liệu được tổ chức theo cách mà ứng dụng không thể biết được

{
	_id: ,
	empDocID: " ObjectId101",
	city: "Hyderabad",
	Area: "Madapur",
	State: "Telangana"
}

7 hỗ trợ tài liệu phong phú. Chúng tôi có thể lưu trữ một mảng các mục, một giá trị cho một khóa nhất định có thể là toàn bộ tài liệu khác. Điều này sẽ cho phép chúng tôi tham gia trước/nhúng dữ liệu để truy cập nhanh. Và điều đó quan trọng bởi vì

//employee
 {
  _id : '25',
   name: 'john doe',
  resume: 30
 }//resume
 {
  _id : '30',
   jobs: [....],
  education: [...],
  employee: 25
 }

1 không hỗ trợ kết nối trực tiếp bên trong kernel. Thay vào đó, nếu chúng ta cần tham gia, chúng ta cần tham gia vào chính ứng dụng. Lý do là các tham gia rất khó mở rộng. Điều này buộc chúng tôi phải suy nghĩ trước về dữ liệu bạn muốn sử dụng cùng với dữ liệu khác. Chúng tôi có thể muốn nhúng dữ liệu trực tiếp vào tài liệu. Không có ràng buộc. Trong trường hợp của

{
	_id: ,
	empDocID: " ObjectId101",
	city: "Hyderabad",
	Area: "Madapur",
	State: "Telangana"
}

7, nó quan trọng như chúng ta nghĩ vì việc nhúng.

{
	_id: ,
	empDocID: " ObjectId101",
	city: "Hyderabad",
	Area: "Madapur",
	State: "Telangana"
}

7 xem xét tính nguyên tử theo cách. Ngoài ra, nó không hỗ trợ các giao dịch, tuy nhiên các hoạt động nguyên tử được hỗ trợ trong một tài liệu. Dữ liệu cần được thiết kế theo cách nó hỗ trợ các hoạt động nguyên tử

Không có lược đồ nào được khai báo nhưng rất có thể một ứng dụng sẽ có lược đồ. Bằng cách có một lược đồ, chúng tôi muốn nói rằng mọi tài liệu trong một bộ sưu tập cụ thể có thể sẽ có cấu trúc khá giống nhau. Có thể có những thay đổi nhỏ đối với cấu trúc đó tùy thuộc vào các phiên bản khác nhau của ứng dụng của bạn. Mặc dù nó không được khai báo trước, nhưng điều quan trọng là phải suy nghĩ về cấu trúc dữ liệu để bản thân lược đồ dữ liệu hỗ trợ tất cả các tính năng khác nhau của ứng dụng của bạn

Chuẩn hóa quan hệ

Hãy xem bảng không chuẩn hóa bên dưới cho một dự án bài đăng trên blog. Nó không phải là dạng bình thường thứ 3, nó bị hỏng. Giả sử có nhiều bài đăng với cùng một tác giả, chúng tôi có thể cập nhật một vài hàng và để những hàng khác không được cập nhật. Để dữ liệu bảng không nhất quán

Do đó, điều này vi phạm chuẩn hóa vì nó vi phạm một cách phổ biến để mô tả các bảng đã chuẩn hóa ở dạng chuẩn hóa thứ 3, đó là mọi thuộc tính không khóa trong bảng phải cung cấp thông tin về khóa, toàn bộ khóa và không có gì khác ngoài khóa. Và đó là một cách chơi chữ cho những gì bạn nói trong phòng xử án ở Hoa Kỳ, nói sự thật, toàn bộ sự thật và không có gì khác ngoài sự thật. Khóa trong trường hợp này là

//employee
 {
  _id : '25',
   name: 'john doe',
  resume: 30
 }//resume
 {
  _id : '30',
   jobs: [....],
  education: [...],
  employee: 25
 }

4 và có một thuộc tính không phải là khóa

//employee
 {
  _id : '25',
   name: 'john doe',
  resume: 30
 }//resume
 {
  _id : '30',
   jobs: [....],
  education: [...],
  employee: 25
 }

5 không tuân theo điều đó. Bởi vì nó thực sự nói lên điều gì đó về tác giả. Và do đó nó vi phạm dạng chuẩn thứ 3 đó

Bảng trên có thể được biểu diễn trong

{
	_id: ,
	empDocID: " ObjectId101",
	city: "Hyderabad",
	Area: "Madapur",
	State: "Telangana"
}

7 dưới dạng

{
  id: 'some id',
  title: 'some title',
  body: 'some content here',
  author: {
    name: 'author name',
    email: 'author email id'
  }
}

Refresher - mục tiêu của quá trình bình thường hóa là gì?

Giải phóng cơ sở dữ liệu khỏi các bất thường sửa đổi — Đối với
```
{
	_id: ,
	empDocID: " ObjectId101",
	city: "Hyderabad",
	Area: "Madapur",
	State: "Telangana"
}
```
7, có vẻ như việc nhúng dữ liệu chủ yếu sẽ gây ra điều này. Và trên thực tế, chúng ta nên cố gắng tránh nhúng dữ liệu vào tài liệu trong
```
{
	_id: ,
	empDocID: " ObjectId101",
	city: "Hyderabad",
	Area: "Madapur",
	State: "Telangana"
}
```
7, điều có thể tạo ra những điểm bất thường này. Đôi khi, chúng tôi có thể cần sao chép dữ liệu trong tài liệu vì lý do hiệu suất. Tuy nhiên đó không phải là cách tiếp cận mặc định. Mặc định là để tránh nó
Nên giảm thiểu thiết kế lại khi mở rộng —
```
{
	_id: ,
	empDocID: " ObjectId101",
	city: "Hyderabad",
	Area: "Madapur",
	State: "Telangana"
}
```
7 đủ linh hoạt vì nó cho phép thêm khóa mà không cần thiết kế lại tất cả tài liệu
Tránh thiên vị đối với bất kỳ mẫu truy cập cụ thể nào — đây là điều mà chúng ta sẽ không phải lo lắng khi mô tả lược đồ trong
```
{
	_id: ,
	empDocID: " ObjectId101",
	city: "Hyderabad",
	Area: "Madapur",
	State: "Telangana"
}
```
7. Và một trong những ý tưởng đằng sau
```
{
	_id: ,
	empDocID: " ObjectId101",
	city: "Hyderabad",
	Area: "Madapur",
	State: "Telangana"
}
```
7 là điều chỉnh cơ sở dữ liệu của bạn cho phù hợp với các ứng dụng mà chúng tôi đang cố gắng viết và vấn đề mà chúng tôi đang cố gắng giải quyết

Một trong những điều tuyệt vời về cơ sở dữ liệu quan hệ là nó thực sự tốt trong việc giữ cho dữ liệu nhất quán trong cơ sở dữ liệu. Một trong những cách thực hiện điều đó là sử dụng khóa ngoại. Một ràng buộc khóa ngoại là giả sử có một bảng với một số cột sẽ có một cột khóa ngoại với các giá trị từ cột của bảng khác. Trong

{
	_id: ,
	empDocID: " ObjectId101",
	city: "Hyderabad",
	Area: "Madapur",
	State: "Telangana"
}

7, không có gì đảm bảo rằng khóa ngoại sẽ được bảo toàn. Lập trình viên phải đảm bảo rằng dữ liệu nhất quán theo cách đó. Điều này có thể khả thi trong các phiên bản tương lai của

{
	_id: ,
	empDocID: " ObjectId101",
	city: "Hyderabad",
	Area: "Madapur",
	State: "Telangana"
}

7 nhưng ngày nay, không có tùy chọn nào như vậy. Giải pháp thay thế cho các ràng buộc khóa ngoại là nhúng dữ liệu

Sống không có giao dịch

Các giao dịch hỗ trợ các thuộc tính ACID nhưng mặc dù không có giao dịch nào trong

{
	_id: ,
	empDocID: " ObjectId101",
	city: "Hyderabad",
	Area: "Madapur",
	State: "Telangana"
}

7, nhưng chúng tôi có các hoạt động nguyên tử. Chà, các phép toán nguyên tử có nghĩa là khi bạn làm việc trên một tài liệu thì công việc đó sẽ được hoàn thành trước khi bất kỳ ai khác nhìn thấy tài liệu đó. Họ sẽ thấy tất cả những thay đổi mà chúng tôi đã thực hiện hoặc không có thay đổi nào. Và bằng cách sử dụng các phép toán nguyên tử, bạn thường có thể hoàn thành điều tương tự mà chúng ta đã hoàn thành bằng cách sử dụng các giao dịch trong cơ sở dữ liệu quan hệ. Và lý do là, trong một cơ sở dữ liệu quan hệ, chúng ta cần thực hiện các thay đổi trên nhiều bảng. Thông thường các bảng cần được nối và vì vậy chúng tôi muốn làm điều đó cùng một lúc. Và để làm điều đó, vì có nhiều bảng, chúng tôi sẽ phải bắt đầu một giao dịch và thực hiện tất cả các cập nhật đó rồi kết thúc giao dịch. Nhưng với

{
	_id: ,
	empDocID: " ObjectId101",
	city: "Hyderabad",
	Area: "Madapur",
	State: "Telangana"
}

7, chúng tôi sẽ nhúng dữ liệu, vì chúng tôi sẽ kết hợp trước dữ liệu đó trong các tài liệu và chúng là những tài liệu phong phú có phân cấp. Chúng ta thường có thể đạt được điều tương tự. Chẳng hạn, trong ví dụ về blog, nếu chúng tôi muốn đảm bảo rằng chúng tôi đã cập nhật nguyên bản một bài đăng trên blog, chúng tôi có thể làm điều đó vì chúng tôi có thể cập nhật toàn bộ bài đăng trên blog cùng một lúc. Nếu như đó là một loạt các bảng quan hệ, chúng tôi có thể phải mở một giao dịch để có thể cập nhật bộ sưu tập bài đăng và bộ sưu tập nhận xét

Vì vậy, những cách tiếp cận mà chúng ta có thể thực hiện trong

{
	_id: ,
	empDocID: " ObjectId101",
	city: "Hyderabad",
	Area: "Madapur",
	State: "Telangana"
}

7 để khắc phục tình trạng thiếu giao dịch là gì?

tái cấu trúc — tái cấu trúc mã, để chúng tôi đang làm việc trong một tài liệu duy nhất và tận dụng các hoạt động nguyên tử mà chúng tôi cung cấp trong tài liệu đó. Và nếu chúng ta làm điều đó, thì thường thì chúng ta đã sẵn sàng
triển khai trong phần mềm — chúng tôi có thể triển khai khóa trong phần mềm bằng cách tạo một phần quan trọng. Chúng tôi có thể xây dựng thử nghiệm, thử nghiệm và thiết lập bằng cách sử dụng tìm và sửa đổi. Chúng ta có thể xây dựng các semaphore, nếu cần. Và theo một cách nào đó, đó là cách thế giới rộng lớn hơn hoạt động. Nếu chúng ta nghĩ về điều đó, nếu một ngân hàng cần chuyển tiền sang ngân hàng khác, họ không sống trong cùng một hệ thống quan hệ. Và họ thường có cơ sở dữ liệu quan hệ riêng. Và họ có thể điều phối hoạt động đó mặc dù chúng tôi không thể bắt đầu giao dịch và kết thúc giao dịch trên các hệ thống cơ sở dữ liệu đó, chỉ trong một hệ thống trong một ngân hàng. Vì vậy, chắc chắn có những cách trong phần mềm để giải quyết vấn đề
khoan dung — cách tiếp cận cuối cùng, thường hoạt động trong các ứng dụng web hiện đại và các ứng dụng khác sử dụng lượng dữ liệu khổng lồ là chỉ chấp nhận một chút không nhất quán. Ví dụ: nếu chúng ta đang nói về nguồn cấp dữ liệu bạn bè trên Facebook, sẽ không có vấn đề gì nếu mọi người thấy cập nhật tường của bạn đồng thời. Nếu được, nếu một người chậm vài nhịp trong vài giây và họ bắt kịp. Trong rất nhiều thiết kế hệ thống, điều quan trọng là mọi thứ phải được giữ hoàn toàn nhất quán và mọi người đều có một cách nhìn hoàn toàn nhất quán và giống nhau về cơ sở dữ liệu. Vì vậy, chúng ta có thể đơn giản chấp nhận một chút mâu thuẫn tạm thời

Các hoạt động

{
	_id: ,
	Emp_ID: "10025AE336"
}

07,

{
	_id: ,
	Emp_ID: "10025AE336"
}

08,

{
	_id: ,
	Emp_ID: "10025AE336"
}

09 (trong một bản cập nhật) &

{
	_id: ,
	Emp_ID: "10025AE336"
}

30 (trong một bản cập nhật) hoạt động nguyên tử trong một tài liệu duy nhất

quan hệ một đối một

Quan hệ 1-1 là quan hệ trong đó mỗi mục tương ứng với chính xác một mục khác. e. g

một nhân viên có một sơ yếu lý lịch và ngược lại
một tòa nhà có và sơ đồ tầng và ngược lại
một bệnh nhân có tiền sử bệnh và ngược lại

//employee
 {
  _id : '25',
   name: 'john doe',
  resume: 30
 }//resume
 {
  _id : '30',
   jobs: [....],
  education: [...],
  employee: 25
 }

Chúng ta có thể lập mô hình quan hệ nhân viên-sơ yếu lý lịch bằng cách có một tập hợp nhân viên và một tập hợp các sơ yếu lý lịch và để nhân viên trỏ đến sơ yếu lý lịch thông qua liên kết, trong đó chúng ta có một

{
	_id: ,
	Emp_ID: "10025AE336"
}

31 tương ứng với một

{
	_id: ,
	Emp_ID: "10025AE336"
}

31 trong tập hợp sơ yếu lý lịch đó. Hoặc nếu muốn, chúng ta có thể liên kết theo một hướng khác, nơi chúng ta có khóa nhân viên bên trong bộ sưu tập sơ yếu lý lịch và nó có thể trỏ đến chính nhân viên đó. Hoặc nếu muốn, chúng ta có thể nhúng. Vì vậy, chúng tôi có thể lấy toàn bộ tài liệu sơ yếu lý lịch này và chúng tôi có thể nhúng nó ngay bên trong bộ sưu tập nhân viên hoặc ngược lại

Việc nhúng này phụ thuộc vào cách ứng dụng truy cập dữ liệu và tần suất dữ liệu được truy cập. Chúng ta cần phải xem xét

tần suất truy cập
kích thước của các mặt hàng - những gì đang phát triển mọi lúc và những gì không phát triển. Vì vậy, mỗi khi chúng tôi thêm một cái gì đó vào tài liệu, có một điểm mà tài liệu cần phải được di chuyển trong bộ sưu tập. Nếu kích thước tài liệu vượt quá 16 MB, điều này hầu như không thể xảy ra
tính nguyên tử của dữ liệu - không có giao dịch nào trong
```
{
	_id: ,
	empDocID: " ObjectId101",
	city: "Hyderabad",
	Area: "Madapur",
	State: "Telangana"
}
```
7, có các hoạt động nguyên tử trên các tài liệu riêng lẻ. Vì vậy, nếu chúng tôi biết rằng chúng tôi không thể chịu được bất kỳ sự không nhất quán nào và chúng tôi muốn có thể cập nhật toàn bộ nhân viên cùng với sơ yếu lý lịch mọi lúc, chúng tôi có thể quyết định đưa chúng vào cùng một tài liệu và nhúng chúng theo cách này hay cách khác.

Mối quan hệ một đến nhiều

Trong mối quan hệ này, có rất nhiều thực thể hoặc nhiều thực thể ánh xạ tới một thực thể. e. g

một thành phố có nhiều người sống trong thành phố đó. Giả sử NYC có 8 triệu người

Giả sử mô hình dữ liệu dưới đây

{
	_id: ,
	Emp_ID: "10025AE336"
}

Điều này sẽ không hiệu quả vì điều đó sẽ THỰC SỰ KHỔNG LỒ. Hãy thử lật đầu

{
	_id: ,
	Emp_ID: "10025AE336"
}

Bây giờ, vấn đề với thiết kế này là nếu rõ ràng có nhiều người sống ở NYC, thì chúng tôi đã thực hiện rất nhiều bản sao cho dữ liệu thành phố

Có lẽ, cách tốt nhất để lập mô hình dữ liệu này là sử dụng liên kết thực

{
	_id: ,
	Emp_ID: "10025AE336"
}

Trong trường hợp này, bộ sưu tập

{
	_id: ,
	Emp_ID: "10025AE336"
}

34 có thể được liên kết với bộ sưu tập

{
	_id: ,
	Emp_ID: "10025AE336"
}

35. Biết rằng chúng tôi không có ràng buộc khóa ngoại, chúng tôi phải nhất quán về điều đó. Vì vậy, đây là một quan hệ nhiều. Nó yêu cầu 2 bộ sưu tập. Đối với một đến ít (cũng là một đến nhiều), các mối quan hệ như bài đăng trên blog với nhận xét. Nhận xét có thể được nhúng bên trong tài liệu bài đăng dưới dạng một mảng

Vì vậy, nếu nó thực sự là một đến nhiều, thì 2 bộ sưu tập hoạt động tốt nhất với liên kết. Nhưng đối với một đến một số ít, một bộ sưu tập nói chung là đủ

Quan hệ nhiều đến nhiều

e. g

sách cho tác giả
học sinh đến giáo viên

Các cuốn sách đối với các tác giả là một mối quan hệ ít nhiều, vì vậy chúng ta có thể có một mảng sách hoặc tác giả bên trong tài liệu của người khác. Đối với học sinh đối với giáo viên cũng vậy. Chúng tôi cũng có thể nhúng vào rủi ro trùng lặp. Tuy nhiên, điều này sẽ yêu cầu mỗi học sinh phải có một giáo viên trong hệ thống trước khi chèn và ngược lại. Logic ứng dụng có thể luôn không cho phép nó. Nói cách khác, đối tượng cha phải tồn tại thì đối tượng con mới tồn tại.

đa phím

Multikey indexes là tính năng giúp liên kết và nhúng hoạt động rất tốt. Giả sử rằng chúng ta có 2 lược đồ cho học sinh và giáo viên

{
	_id: ,
	empDocID: " ObjectId101",
	First_Name: "Radhika",
	Last_Name: "Sharma",
	Date_Of_Birth: "1995-09-26"
}

Bây giờ có 2 truy vấn rõ ràng

Làm thế nào để tìm tất cả các giáo viên mà một học sinh cụ thể đã có?
Làm thế nào để tìm tất cả các sinh viên đã có một giáo viên cụ thể? . Và để đạt được điều đó, chúng ta cần phải hiệu quả, chúng ta cần sử dụng các chỉ mục Multikey

Để tạo một chỉ mục trên cột

{
	_id: ,
	Emp_ID: "10025AE336"
}

37 trên bộ sưu tập

{
	_id: ,
	Emp_ID: "10025AE336"
}

38, hãy sử dụng

{
	_id: ,
	Emp_ID: "10025AE336"
}

Bây giờ để tìm tất cả các sinh viên đã có một giáo viên cụ thể? . Bây giờ, nếu chúng ta thêm

{
	_id: ,
	Emp_ID: "10025AE336"
}

91 vào truy vấn trên - nó cho thấy hoạt động bên trong bằng cách hiển thị vị trí các phím được áp dụng, v.v.

Lợi ích của việc nhúng

Lý do chính để nhúng tài liệu vào

{
	_id: ,
	empDocID: " ObjectId101",
	city: "Hyderabad",
	Area: "Madapur",
	State: "Telangana"
}

7 là hiệu suất. Lợi ích hiệu suất chính đến từ hiệu suất đọc được cải thiện. Bây giờ, tại sao chúng ta nhận được hiệu suất đọc. Lý do là bản chất của cách hệ thống máy tính được xây dựng, đó là chúng thường có đĩa quay và những đĩa quay đó có độ trễ rất cao, có nghĩa là chúng mất rất nhiều thời gian (tối đa 1ms) để truy cập byte đầu tiên. Tuy nhiên, khi byte đầu tiên được truy cập, mỗi byte bổ sung sẽ đến rất nhanh. Vì vậy, chúng có xu hướng có băng thông khá cao. Vì vậy, ý tưởng là nếu chúng ta có thể định vị dữ liệu được sử dụng cùng nhau trong cùng một tài liệu, nhúng nó và sau đó chúng ta sẽ quay đĩa, tìm khu vực mà chúng ta cần thông tin này và sau đó chúng ta sẽ bắt đầu đọc . Và chúng tôi sẽ nhận được tất cả thông tin chúng tôi cần trong một lần. Ngoài ra, điều đó có nghĩa là nếu chúng ta có 2 mẩu dữ liệu thường nằm trong 2 bộ sưu tập hoặc trong một số bảng cơ sở dữ liệu quan hệ. Thay vào đó, chúng ở trong một tài liệu, chúng tôi tránh các chuyến đi vòng quanh cơ sở dữ liệu

Cây

Một vấn đề kinh điển trong thế giới thiết kế lược đồ là làm thế nào để bạn biểu diễn một cây bên trong cơ sở dữ liệu? . Nơi chúng ta có nhà, ngoài trời, mùa đông, tuyết. Và ý tưởng là chúng ta có

{
	_id: ,
	Emp_ID: "10025AE336"
}

93. Ngoài ra, chúng tôi có một

{
	_id: ,
	Emp_ID: "10025AE336"
}

94, nơi chúng tôi có thể tra cứu danh mục 7 và xem

{
	_id: ,
	Emp_ID: "10025AE336"
}

95, một số thuộc tính của

{
	_id: ,
	Emp_ID: "10025AE336"
}

{
	_id: ,
	empDocID: " ObjectId101",
	e-mail: "[email protected]",
	phone: "9848022338"
}

Một cách để làm điều đó là giữ id

{
	_id: ,
	Emp_ID: "10025AE336"
}

97 - đây có thể là điều chúng ta có thể làm trong cơ sở dữ liệu quan hệ đơn giản. Nhưng điều này không giúp bạn dễ dàng tìm thấy tất cả các

{
	_id: ,
	Emp_ID: "10025AE336"
}

97 cho đến

{
	_id: ,
	Emp_ID: "10025AE336"
}

94 này. Chúng tôi phải truy vấn lặp đi lặp lại, tìm cha của cái này và cha của cái kia cho đến khi chúng tôi đi đến đầu trang

Vì vậy, một cách khác để làm điều đó trong

{
	_id: ,
	empDocID: " ObjectId101",
	city: "Hyderabad",
	Area: "Madapur",
	State: "Telangana"
}

7 là có thể liệt kê tổ tiên hoặc con cái. Vì vậy, hãy nghĩ về điều đó và cách thức hoạt động của nó. Vì vậy, chúng tôi có thể quyết định liệt kê tất cả những đứa trẻ của

{
	_id: ,
	Emp_ID: "10025AE336"
}

94 này

{
	_id: ,
	empDocID: " ObjectId101",
	e-mail: "[email protected]",
	phone: "9848022338"
}

Điều đó cũng khá hạn chế, nếu chúng ta muốn có thể nhìn và tìm thấy toàn bộ cây con phía trên một phần cây nhất định. Thay vào đó, thứ hoạt động khá tốt và một lần nữa, kích hoạt khả năng đặt mảng bên trong

{
	_id: ,
	empDocID: " ObjectId101",
	city: "Hyderabad",
	Area: "Madapur",
	State: "Telangana"
}

7 là liệt kê tổ tiên từ trên xuống theo thứ tự

{
	_id: ,
	empDocID: " ObjectId101",
	e-mail: "[email protected]",
	phone: "9848022338"
}

Một lần nữa, khả năng cấu trúc và thể hiện dữ liệu phong phú là một trong những điều khiến

{
	_id: ,
	empDocID: " ObjectId101",
	city: "Hyderabad",
	Area: "Madapur",
	State: "Telangana"
}

7 trở nên thú vị. Điều này sẽ rất khó thực hiện trong cơ sở dữ liệu quan hệ. Bây giờ, về cách bạn trình bày dữ liệu cho thứ gì đó như hệ thống phân cấp ________ 224 ________ 194, một lần nữa, tất cả phụ thuộc vào các mẫu truy cập. Nó phụ thuộc vào cách chúng tôi tin rằng chúng tôi sẽ cần hiển thị dữ liệu, truy cập dữ liệu cho người dùng. Và sau đó dựa vào đó, chúng tôi biết cách mô hình hóa nó

Khi nào cần chuẩn hóa

Một trong những lý do để chuẩn hóa trong cơ sở dữ liệu quan hệ là để tránh các bất thường sửa đổi đi kèm với việc sao chép dữ liệu. Và khi chúng tôi xem xét

{
	_id: ,
	empDocID: " ObjectId101",
	city: "Hyderabad",
	Area: "Madapur",
	State: "Telangana"
}

7 và cách nó được cấu trúc, cho phép các tài liệu phong phú này, thật dễ dàng cho rằng những gì chúng tôi đang làm là chúng tôi đang chuẩn hóa dữ liệu. Và ở một mức độ nào đó, điều đó đúng. Miễn là chúng tôi không sao chép dữ liệu, chúng tôi không tự mở cho những bất thường sửa đổi

Nói chung, thật tốt khi nhúng dữ liệu đó trong trường hợp có mối quan hệ 1-1. Trong trường hợp có mối quan hệ từ một đến nhiều, quá trình nhúng cũng có thể hoạt động tốt mà không cần sao chép dữ liệu miễn là chúng ta nhúng từ nhiều vào một. Bây giờ, nếu chúng ta đi từ một đến nhiều, thì việc liên kết sẽ tránh được sự trùng lặp dữ liệu. Bây giờ, nếu chúng ta muốn nhúng thứ gì đó, ngay cả khi nó gây ra sự trùng lặp dữ liệu vì lý do hiệu suất để phù hợp với kiểu truy cập của ứng dụng. Điều đó có thể hợp lý, đặc biệt nếu dữ liệu hiếm khi thay đổi hoặc được cập nhật. Nhưng chúng ta có thể tránh nó thường xuyên, ngay cả trong mối quan hệ này, nếu chúng ta đi từ nhiều đến một. Trong mối quan hệ nhiều-nhiều, mà chúng ta đã xem xét với

{
	_id: ,
	Emp_ID: "10025AE336"
}

38 và

{
	_id: ,
	Emp_ID: "10025AE336"
}

37 và

{
	_id: ,
	empDocID: " ObjectId101",
	First_Name: "Radhika",
	Last_Name: "Sharma",
	Date_Of_Birth: "1995-09-26"
}

29 và

{
	_id: ,
	empDocID: " ObjectId101",
	e-mail: "[email protected]",
	phone: "9848022338"
}

30, ở đó nếu bạn muốn tránh những bất thường sửa đổi đi kèm với việc không chuẩn hóa, tất cả những gì chúng ta cần làm là liên kết thông qua các mảng của

{
	_id: ,
	empDocID: " ObjectId101",
	e-mail: "[email protected]",
	phone: "9848022338"
}

31 trong tài liệu

Đây là tất cả các hướng dẫn. Đối với ứng dụng trong thế giới thực, chúng tôi có thể cần nhúng dữ liệu vì lý do hiệu suất, để phù hợp với các mẫu truy cập dữ liệu — — có thể cần nhúng dữ liệu

Bạn có thể tạo một lược đồ trong MongoDB không?

Như chúng ta đã biết MongoDB không có lược đồ, tại thời điểm tạo bất kỳ đối tượng nào, chúng tôi không thể tạo bất kỳ lược đồ nào trong MongoDB . Chúng ta có thể thực thi lược đồ cho bộ sưu tập trong MongoDB bằng cách sử dụng cụm tập bản đồ MongoDB, để thực thi lược đồ tài liệu, trước tiên chúng ta cần kết nối cơ sở dữ liệu và bộ sưu tập.

Lược đồ MongoDB là gì?

Lược đồ là gì? . Bạn có thể sử dụng lược đồ BSON của Atlas App Services, mở rộng tiêu chuẩn Lược đồ JSON, để xác định mô hình dữ liệu của ứng dụng và xác thực tài liệu bất cứ khi nào chúng được tạo, thay đổi hoặc xóa. a JSON object that defines the the structure and contents of your data. You can use Atlas App Services' BSON schemas, which extend the JSON Schema standard, to define your application's data model and validate documents whenever they're created, changed, or deleted.

Tôi có thể tìm lược đồ MongoDB ở đâu?

Chúng ta có thể lấy đối tượng lược đồ/tài liệu đầu tiên của bộ sưu tập bằng cách sử dụng. var schemaObj = db. người dùng. findOne();

Lược đồ MongoDB có miễn phí không?

MongoDB có phải là sơ đồ không? . MongoDB is considered schemaless because it does not require a rigid, pre-defined schema like a relational database.

programming mongodb

Lược đồ mẫu MongoDB

Thiết kế mô hình dữ liệu

Mô hình dữ liệu nhúng

Mô hình dữ liệu chuẩn hóa

Những lưu ý khi thiết kế Schema trong MongoDB

Thí dụ

Bạn có thể tạo một lược đồ trong MongoDB không?

Lược đồ MongoDB là gì?

Tôi có thể tìm lược đồ MongoDB ở đâu?

Lược đồ MongoDB có miễn phí không?

Bài Viết Liên Quan

Quảng Cáo

Có thể bạn quan tâm

Toplist được quan tâm

Quảng cáo

Xem Nhiều

Quảng cáo

Chúng tôi

Điều khoản

Trợ giúp

Mạng xã hội