MongoDB - modelowanie danych

Dane w MongoDB mają elastyczny schemat schema.documents w tej samej kolekcji. Nie muszą mieć tego samego zestawu pól ani struktury. Wspólne pola w dokumentach kolekcji mogą zawierać różne typy danych.

Projektowanie modelu danych

MongoDB udostępnia dwa typy modeli danych: - Wbudowany model danych i znormalizowany model danych. W zależności od wymagań podczas przygotowywania dokumentu możesz użyć dowolnego z modeli.

Wbudowany model danych

W tym modelu można mieć (osadzać) wszystkie powiązane dane w jednym dokumencie, jest to również znane jako zdenormalizowany model danych.

Na przykład załóżmy, że pobieramy dane pracowników w trzech różnych dokumentach, a mianowicie Personal_details, Contact i Address, możesz osadzić wszystkie trzy dokumenty w jednym, jak pokazano poniżej -

{
	_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" } } 
      

Znormalizowany model danych

W tym modelu możesz odwołać się do dokumentów podrzędnych w oryginalnym dokumencie, używając odniesień. Na przykład możesz ponownie napisać powyższy dokument w znormalizowanym modelu jako:

Employee:

{
	_id: <ObjectId101>,
	Emp_ID: "10025AE336"
}

Personal_details:

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

Contact:

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

Address:

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

Zagadnienia dotyczące projektowania schematu w MongoDB

• Zaprojektuj swój schemat zgodnie z wymaganiami użytkownika.

• Połącz obiekty w jeden dokument, jeśli będziesz ich używać razem. W przeciwnym razie rozdziel je (ale upewnij się, że nie ma potrzeby łączenia).

• Powiel dane (ale ograniczone), ponieważ miejsce na dysku jest tanie w porównaniu z czasem obliczeniowym.

• Łączenia wykonuj podczas zapisu, a nie podczas czytania.

• Zoptymalizuj swój schemat pod kątem najczęstszych przypadków użycia.

• Wykonaj złożoną agregację w schemacie.

Przykład

Załóżmy, że klient potrzebuje projektu bazy danych dla swojego bloga / witryny internetowej i widzi różnice między projektami schematów RDBMS i MongoDB. Witryna ma następujące wymagania.

• Każdy post ma unikalny tytuł, opis i adres URL.

• Każdy post może mieć jeden lub więcej tagów.

• Każdy post ma nazwę wydawcy i całkowitą liczbę polubień.

• Każdy post ma komentarze dodane przez użytkowników wraz z ich imieniem i nazwiskiem, wiadomością, datą i polubieniami.

• Każdy post może zawierać zero lub więcej komentarzy.

W schemacie RDBMS projekt dla powyższych wymagań będzie miał minimum trzy tabele.

W schemacie MongoDB projekt będzie miał jeden wpis kolekcji i następującą strukturę -

{
   _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
      }
   ]
}

Tak więc podczas wyświetlania danych w RDBMS musisz połączyć trzy tabele, aw MongoDB dane będą wyświetlane tylko z jednej kolekcji.