Apakah mongodb mendukung batasan kunci asing

Sebelum menjelajahi skema yang lebih lanjut dalam buku ini, penting untuk meninjau kembali dasar-dasar skema. Dalam bab ini kita akan mengeksplorasi hubungan dasar dari database relasional tradisional dan bagaimana hubungannya dengan model dokumen di MongoDB

Kita akan mulai dengan melihat One-To-One (1. 1) hubungan kemudian beralih ke One-To-Many (1. N) dan akhirnya Many-To-Many (N. M)

Satu Ke Satu (1. 1)

1. 1 hubungan menggambarkan hubungan antara dua entitas. Dalam hal ini Penulis memiliki hubungan Alamat tunggal di mana seorang Penulis tinggal di satu Alamat dan Alamat hanya berisi satu Penulis

1. 1 hubungan dapat dimodelkan dalam dua cara menggunakan MongoDB. Yang pertama adalah menyematkan relasi sebagai dokumen, yang kedua sebagai tautan ke dokumen dalam koleksi terpisah. Mari kita lihat kedua cara memodelkan hubungan satu ke satu menggunakan dua dokumen berikut

Model

{
  name: "Peter Wilkinson",
  age: 27
}

Angka. Contoh dokumen Pengguna

{
  street: "100 some road",
  city: "Nevermore"
}

_

Angka. Contoh dokumen Alamat

Menyematkan

Pendekatan pertama adalah menyematkan dokumen Alamat sebagai dokumen yang disematkan di dokumen Pengguna

{
  name: "Peter Wilkinson",
  age: 27,
  address: {
    street: "100 some road",
    city: "Nevermore"
  }
}

Angka. Contoh dokumen Pengguna dengan Alamat Tertanam

Kekuatan menyematkan dokumen Alamat langsung di dokumen Pengguna adalah bahwa kita dapat mengambil pengguna dan alamatnya dalam operasi baca tunggal dibandingkan harus terlebih dahulu membaca dokumen pengguna dan kemudian dokumen alamat untuk pengguna tertentu tersebut. Karena alamat memiliki kedekatan yang kuat dengan dokumen pengguna, penyematan masuk akal di sini

Menautkan

Pendekatan kedua adalah menautkan alamat dan dokumen pengguna menggunakan

{
  name: "Peter Wilkinson",
  age: 27,
  address: {
    street: "100 some road",
    city: "Nevermore"
  }
}

0

{
  _id: 1,
  name: "Peter Wilkinson",
  age: 27
}

_

Angka. Contoh dokumen Pengguna

{
  user_id: 1,
  street: "100 some road",
  city: "Nevermore"
}

Angka. Contoh dokumen Alamat dengan Kunci Asing

Ini mirip dengan bagaimana database relasional tradisional akan menyimpan data. Penting untuk dicatat bahwa MongoDB tidak menerapkan batasan kunci asing apa pun sehingga relasi hanya ada sebagai bagian dari skema level aplikasi

penting

{
  name: "Peter Wilkinson",
  age: 27,
  address: {
    street: "100 some road",
    city: "Nevermore"
  }
}

1

Dalam hubungan satu ke satu Penyematan adalah cara yang lebih disukai untuk memodelkan hubungan karena lebih efisien untuk mengambil dokumen

Satu Ke Banyak (1. N)

1. Relasi N menggambarkan relasi dimana satu pihak dapat memiliki lebih dari satu relasi sedangkan relasi sebaliknya hanya dapat satu sisi. Contohnya adalah Blog di mana sebuah blog mungkin memiliki banyak Komentar tetapi sebuah Komentar hanya terkait dengan satu Blog

1. Hubungan N dapat dimodelkan dalam beberapa cara berbeda menggunakan MongoDB. Dalam bab ini kita akan mengeksplorasi tiga cara berbeda untuk memodelkan 1. hubungan N. Yang pertama adalah penyematan, yang kedua adalah penautan dan yang ketiga adalah strategi pengelompokan yang berguna untuk kasus seperti deret waktu. Mari gunakan model

{
  name: "Peter Wilkinson",
  age: 27,
  address: {
    street: "100 some road",
    city: "Nevermore"
  }
}

2 dan

{
  name: "Peter Wilkinson",
  age: 27,
  address: {
    street: "100 some road",
    city: "Nevermore"
  }
}

3

Model

{
  title: "An awesome blog",
  url: "http://awesomeblog.com",
  text: "This is an awesome blog we have just started"
}

_

Angka. Contoh dokumen Posting Blog

Posting Blog adalah satu dokumen yang menjelaskan satu posting blog tertentu

{
  name: "Peter Critic",
  created_on: ISODate("2014-01-01T10:01:22Z"),
  comment: "Awesome blog post"
}
{
  name: "John Page",
  created_on: ISODate("2014-01-01T11:01:22Z"),
  comment: "Not so awesome blog"
}

Angka. Beberapa contoh dokumen Komentar

Untuk setiap Posting Blog kita dapat memiliki satu atau lebih Komentar

Menyematkan

Pendekatan pertama adalah menyematkan Komentar di

{
  name: "Peter Wilkinson",
  age: 27,
  address: {
    street: "100 some road",
    city: "Nevermore"
  }
}

2

{
  title: "An awesome blog",
  url: "http://awesomeblog.com",
  text: "This is an awesome blog we have just started",
  comments: [{
    name: "Peter Critic",
    created_on: ISODate("2014-01-01T10:01:22Z"),
    comment: "Awesome blog post"
  }, {
    name: "John Page",
    created_on: ISODate("2014-01-01T11:01:22Z"),
    comment: "Not so awesome blog"
  }]
}

Angka. Posting Blog dengan dokumen yang disematkan

Penyematan

{
  name: "Peter Wilkinson",
  age: 27,
  address: {
    street: "100 some road",
    city: "Nevermore"
  }
}

_5 di posting Blog berarti kita dapat dengan mudah mengambil semua komentar milik posting Blog tertentu. Menambahkan komentar baru semudah menambahkan dokumen komentar baru ke akhir larik

{
  name: "Peter Wilkinson",
  age: 27,
  address: {
    street: "100 some road",
    city: "Nevermore"
  }
}

5

Namun, ada tiga masalah potensial yang terkait dengan pendekatan ini yang harus diwaspadai

• Yang pertama adalah bahwa array

  {
    name: "Peter Wilkinson",
    age: 27,
    address: {
      street: "100 some road",
      city: "Nevermore"
    }
  }
  

  _5 mungkin tumbuh lebih besar dari ukuran dokumen maksimum

  {
    name: "Peter Wilkinson",
    age: 27,
    address: {
      street: "100 some road",
      city: "Nevermore"
    }
  }
  

  8
• Aspek kedua berkaitan dengan kinerja menulis. Karena komentar ditambahkan ke Posting Blog dari waktu ke waktu, menjadi sulit bagi MongoDB untuk memprediksi padding dokumen yang benar untuk diterapkan saat dokumen baru dibuat. MongoDB perlu mengalokasikan ruang baru untuk dokumen yang berkembang. Selain itu, ia harus menyalin dokumen ke lokasi memori baru dan memperbarui semua indeks. Ini dapat menyebabkan beban IO lebih banyak dan dapat memengaruhi kinerja penulisan secara keseluruhan

penting

Penting untuk dicatat bahwa ini hanya penting untuk lalu lintas penulisan yang tinggi dan mungkin tidak menjadi masalah untuk aplikasi yang lebih kecil. Apa yang mungkin tidak dapat diterima untuk aplikasi volume tulis tinggi mungkin dapat ditoleransi untuk aplikasi dengan beban tulis rendah

• Masalah ketiga terungkap ketika seseorang mencoba melakukan penomoran halaman pada komentar. Tidak ada cara untuk membatasi komentar yang dikembalikan dari

  {
    name: "Peter Wilkinson",
    age: 27,
    address: {
      street: "100 some road",
      city: "Nevermore"
    }
  }
  

  2 menggunakan temuan normal sehingga kami harus mengambil seluruh dokumen blog dan memfilter komentar di aplikasi kami

Menautkan

Pendekatan kedua adalah menautkan komentar ke

{
  name: "Peter Wilkinson",
  age: 27,
  address: {
    street: "100 some road",
    city: "Nevermore"
  }
}

_2 menggunakan kunci

{
  _id: 1,
  name: "Peter Wilkinson",
  age: 27
}

1 yang lebih tradisional

{
  _id: 1,
  title: "An awesome blog",
  url: "http://awesomeblog.com",
  text: "This is an awesome blog we have just started"
}

Angka. Contoh dokumen Posting Blog

{
  blog_entry_id: 1,
  name: "Peter Critic",
  created_on: ISODate("2014-01-01T10:01:22Z"),
  comment: "Awesome blog post"
}
{
  blog_entry_id: 1,
  name: "John Page",
  created_on: ISODate("2014-01-01T11:01:22Z"),
  comment: "Not so awesome blog"
}

Angka. Beberapa contoh dokumen Komentar dengan Kunci Asing

Keuntungan model ini adalah bahwa komentar tambahan tidak akan menumbuhkan dokumen

{
  name: "Peter Wilkinson",
  age: 27,
  address: {
    street: "100 some road",
    city: "Nevermore"
  }
}

2 asli, sehingga kecil kemungkinan aplikasi akan berjalan dalam ukuran dokumen maksimum

{
  name: "Peter Wilkinson",
  age: 27,
  address: {
    street: "100 some road",
    city: "Nevermore"
  }
}

8. Juga jauh lebih mudah untuk mengembalikan komentar dengan halaman karena aplikasi dapat memotong dan memotong komentar dengan lebih mudah. Sisi negatifnya jika kita memiliki 1000 komentar pada posting blog, kita perlu mengambil semua 1000 dokumen yang menyebabkan banyak pembacaan dari database

Bucket

Pendekatan ketiga adalah gabungan dari dua pendekatan di atas. Pada dasarnya, mencoba untuk menyeimbangkan kekakuan dari strategi embedding dengan fleksibilitas dari strategi linking. Untuk contoh ini, kami akan membagi komentar ke dalam keranjang dengan maksimal 50 komentar di setiap keranjang

{
  _id: 1,
  title: "An awesome blog",
  url: "http://awesomeblog.com",
  text: "This is an awesome blog we have just started"
}

Angka. Contoh dokumen Posting Blog

{
  street: "100 some road",
  city: "Nevermore"
}

_1

Angka. Beberapa contoh keranjang Komentar

Manfaat utama menggunakan bucket dalam hal ini adalah kita dapat melakukan sekali baca untuk mengambil 50 komentar sekaligus, memungkinkan paginasi yang efisien

penting

{
  _id: 1,
  name: "Peter Wilkinson",
  age: 27
}

_4

Saat Anda memiliki kemungkinan untuk membagi dokumen Anda menjadi beberapa kumpulan rahasia, masuk akal untuk mempertimbangkan pengelompokan untuk mempercepat pengambilan dokumen

Kasus umum di mana pengelompokan sesuai adalah seperti pengelompokan data menurut jam, hari, atau jumlah entri pada halaman (seperti paginasi komentar)

Banyak-ke-banyak (N. M)

sebuah N. Relasi M adalah contoh relasi antara dua entitas dimana keduanya mungkin memiliki banyak relasi antara satu sama lain. Contohnya mungkin Buku yang ditulis oleh banyak Penulis. Pada saat yang sama seorang Penulis mungkin telah menulis banyak Buku

N. M hubungan dimodelkan dalam database relasional dengan menggunakan tabel gabungan. Contoh yang baik adalah hubungan antara buku dan penulis

• Seorang penulis mungkin telah menulis banyak buku (1. N)
• Sebuah buku mungkin memiliki banyak penulis (1. M)

Ini mengarah ke N. M hubungan antara penulis buku. Mari kita lihat bagaimana ini bisa dimodelkan

Penyematan Dua Arah

Menyematkan buku dalam dokumen Penulis

Model

Di

{
  _id: 1,
  name: "Peter Wilkinson",
  age: 27
}

_5 kami akan menyertakan Buku

{
  _id: 1,
  name: "Peter Wilkinson",
  age: 27
}

6 di bawah bidang

{
  _id: 1,
  name: "Peter Wilkinson",
  age: 27
}

7

{
  street: "100 some road",
  city: "Nevermore"
}

_2

Angka. Beberapa contoh dokumen Penulis

Mencerminkan dokumen Penulis, untuk setiap Buku kami menyertakan Penulis

{
  _id: 1,
  name: "Peter Wilkinson",
  age: 27
}

6 di bawah bidang Penulis

{
  street: "100 some road",
  city: "Nevermore"
}

_3

Angka. Beberapa contoh dokumen Buku

Kueri

{
  street: "100 some road",
  city: "Nevermore"
}

_4

Contoh 1. Ambil buku oleh penulis tertentu

{
  street: "100 some road",
  city: "Nevermore"
}

_5

Contoh 2. Ambil penulis dari buku tertentu

Seperti yang bisa dilihat, kita harus melakukan dua kueri di kedua arah. Yang pertama adalah menemukan penulis atau bukunya dan yang kedua adalah melakukan kueri $in untuk menemukan buku atau penulisnya

penting

{
  _id: 1,
  name: "Peter Wilkinson",
  age: 27
}

_9

Mari kita ambil kategori

{
  user_id: 1,
  street: "100 some road",
  city: "Nevermore"
}

_0 yang mungkin memiliki ribuan buku di dalamnya dan dengan banyak buku baru yang ditambahkan dan dihapus secara konsisten. Ini membuatnya tidak praktis untuk menyematkan semua buku dalam dokumen kategori. Namun, setiap buku dapat dengan mudah memiliki kategori yang disematkan di dalamnya, karena tingkat perubahan kategori untuk buku tertentu mungkin sangat rendah.

Dalam hal ini kita harus mempertimbangkan

{
  user_id: 1,
  street: "100 some road",
  city: "Nevermore"
}

_1 sebagai strategi

Penyematan Satu Arah

Strategi Penyematan Satu Arah memilih untuk mengoptimalkan kinerja baca N. M hubungan dengan menyematkan referensi di satu sisi hubungan. Contohnya mungkin di mana beberapa buku termasuk dalam beberapa kategori tetapi beberapa kategori memiliki banyak buku. Mari kita lihat sebuah contoh, menarik kategori ke dalam dokumen terpisah

Model

{
  street: "100 some road",
  city: "Nevermore"
}

_6

Angka. Dokumen Kategori

{
  street: "100 some road",
  city: "Nevermore"
}

_7

Angka. Buku dengan Kunci Asing untuk Kategori

Alasan kami memilih untuk menyematkan semua referensi kategori dalam buku adalah karena ada lebih banyak buku dalam kategori drama daripada kategori dalam sebuah buku. Jika seseorang menyematkan buku dalam dokumen kategori, mudah untuk memperkirakan bahwa seseorang dapat memecahkan ukuran dokumen maksimal 16MB untuk kategori luas tertentu

Kueri

{
  street: "100 some road",
  city: "Nevermore"
}

_8

Contoh 3. Ambil kategori untuk buku tertentu

{
  street: "100 some road",
  city: "Nevermore"
}

_9

Contoh 4. Ambil buku untuk kategori tertentu

tip

{
  user_id: 1,
  street: "100 some road",
  city: "Nevermore"
}

2

Tetapkan ukuran maksimum

{
  user_id: 1,
  street: "100 some road",
  city: "Nevermore"
}

_3 dan ukuran

{
  user_id: 1,
  street: "100 some road",
  city: "Nevermore"
}

4. Misalnya jika

{
  user_id: 1,
  street: "100 some road",
  city: "Nevermore"
}

_3 maksimal 3 kategori untuk sebuah buku dan

{
  user_id: 1,
  street: "100 some road",
  city: "Nevermore"
}

4 maksimal 500000 buku dalam satu kategori, Anda harus memilih Penyematan Satu Arah. Jika

{
  user_id: 1,
  street: "100 some road",
  city: "Nevermore"
}

_3 maksimal 3 dan

{
  user_id: 1,
  street: "100 some road",
  city: "Nevermore"
}

4 maksimal 5 maka Penyematan Dua Arah mungkin bekerja dengan baik

Bisakah Anda memiliki kunci asing di MongoDB?

Apakah MongoDB mendukung kunci utama

Bisakah kita memiliki kendala di MongoDB?

Apakah NoSQL mendukung kunci asing?