‫Narator: Salah satu langkah
‫terpenting dalam membangun aplikasi intensif data adalah benar-benar
‫memodelkan semua data ini di MongoDB.
‫Dan itulah yang akan kita bicarakan dalam kuliah ini.
‫Jadi, sangat penting bagi Anda untuk
‫mengikutinya bahkan pada awalnya banyak yang harus diambil. Baiklah.
‫Bagaimanapun, mari kita mulai sekarang.
‫Sekarang, pemodelan data mungkin merupakan konsep yang sangat baru bagi Anda.
‫Jadi sebelum kita
‫mulai; mari kita perjelas apa yang sebenarnya akan kita bicarakan.
‫Jadi, pemodelan data adalah proses pengambilan data tidak
‫terstruktur yang dihasilkan oleh skenario dunia nyata
‫dan kemudian menyusunnya menjadi model data logis
‫dalam database.
‫Dan kami melakukannya sesuai dengan serangkaian
‫kriteria yang akan kami pelajari di video ini.
‫Sebagai contoh; katakanlah kita ingin merancang
‫model data toko online.
‫Awalnya akan ada satu ton data tidak terstruktur yang kami
‫tahu kami butuhkan.
‫Benar.
‫Barang-barang seperti produk,
‫kategori, pesanan pelanggan, keranjang belanja, pemasok.
‫Dan seterusnya dan seterusnya.
‫Tujuan kami dengan pemodelan data adalah untuk kemudian menyusun
‫data ini menjadi cara yang logis.
‫Mencerminkan hubungan dunia nyata yang
‫ada di antara beberapa kumpulan data ini.
‫Sedikit seperti yang Anda lihat dalam contoh ini.
‫Dan ini tentu saja hanya semacam situasi imajiner tetapi
‫Anda mendapatkan idenya.
‫Benar.
‫Sekarang, banyak pengembang backend mengatakan bahwa pemodelan data adalah hal
‫yang paling kita harus pikirkan.
‫Itu adalah bagian yang paling menuntut dalam
‫membangun seluruh aplikasi.
‫Karena itu benar-benar tidak selalu lurus ke depan.
‫Dan terkadang tidak ada jawaban yang benar.
‫Jadi bukan hanya satu cara unik yang benar untuk menyusun data.
‫Tapi bagaimanapun saya akan melakukan yang terbaik untuk meletakkan proses
‫dalam video ini.
‫Dan untuk itu kita akan melalui empat langkah.
‫Jadi pada langkah pertama; kami belajar tentang bagaimana
‫mengidentifikasi berbagai jenis hubungan antara data.
‫Kemudian
‫kita akan memahami perbedaan antara
‫referensi atau normalisasi dan embedding atau denormalisasi.
‫Pada langkah berikutnya dan
‫yang paling penting; Saya akan menunjukkan kerangka
‫kerja saya untuk memutuskan apakah
‫kita harus menyematkan dokumen atau merujuk
‫ke dokumen lain berdasarkan beberapa faktor yang berbeda.
‫Juga, kita harus cepat berbicara
‫tentang berbagai jenis referensi.
‫Karena itu penting jika itu adalah jenis desain yang
‫kita pilih untuk data kita.
‫Jadi ini sebenarnya akan menjadi kuliah yang cukup teoretis.
‫Tetapi juga sangat penting untuk kemajuan Anda
‫sebagai pengembang back-end.
‫Karena cara kita mendesain data sehingga cara kita memodelkan data
‫kita dapat membuat atau menghancurkan seluruh aplikasi kita.
‫Dan akan ada banyak contoh di sepanjang jalan untuk
‫membuat proses ini lebih mudah.
‫Baiklah.
‫Dan hal pertama yang
‫akan kita bicarakan adalah berbagai jenis
‫hubungan yang ada di antara data.
‫Jadi ada tiga jenis besar hubungan.
‫Satu ke satu, satu ke banyak, dan banyak ke banyak.
‫Dan saya akan menggunakan aplikasi
‫film sebagai contoh di slide ini.
‫Oke?
‫Jadi pertama, hubungan satu ke satu
‫antara data pada dasarnya
‫adalah ketika satu bidang hanya dapat memiliki satu nilai.
‫Jadi dalam contoh aplikasi film kami; satu film hanya pernah
‫memiliki satu nama.
‫Jadi ini adalah contoh
‫sederhana dari hubungan satu lawan satu.
‫Tetapi hubungan ini tidak terlalu penting dalam
‫hal pemodelan data.
‫Sekarang hubungan yang paling
‫penting adalah hubungan satu ke banyak.
‫Dan mereka sangat penting sehingga di
‫MongoDB kami benar-benar membedakan antara tiga jenis
‫hubungan satu ke banyak.
‫Satu ke beberapa, satu ke banyak, dan satu ke satu ton atau ke satu juta
‫atau sesuatu seperti itu. Jadi perbedaan di sini
‫didasarkan pada jumlah relatif banyak. Baiklah.
‫Jadi contoh hubungan satu ke beberapa
‫adalah bahwa satu film dapat memenangkan banyak penghargaan tetapi sebenarnya hanya sedikit.
‫Jadi film tidak akan memenangkan seribu penghargaan tetapi
‫bisa memenangkan beberapa.
‫Jadi ini adalah tipikal hubungan satu ke beberapa.
‫Jadi Anda melihat bahwa secara umum hubungan satu ke
‫banyak berarti bahwa satu dokumen dapat berhubungan dengan banyak dokumen lainnya.
‫Sekarang ini mungkin terlihat agak abstrak tanpa data JSON tetapi
‫sebenarnya itulah tujuannya di sini.
‫Saya hanya ingin menunjukkan gambaran
‫konseptual dari berbagai jenis hubungan ini.
‫Bagaimanapun, setiap hubungan satu ke banyak
‫satu dokumen dapat berhubungan dengan ratusan atau ribuan
‫dokumen lainnya.
‫Sebagai contoh; satu film dapat memiliki ribuan
‫ulasan di aplikasi kami.
‫Jadi ini bukan hubungan satu ke sedikit tetapi
‫satu ke banyak. Oke?
‫Dan akhirnya kami memiliki hubungan satu lawan satu.
‫Bayangkan kami ingin menerapkan beberapa fungsi logging di
‫aplikasi kami. Jadi pada dasarnya untuk tahu
‫persis apa yang terjadi di server kami.
‫Log ini kemudian dapat dengan mudah berkembang menjadi jutaan dokumen.
‫Jadi ini adalah contoh yang
‫sangat khas dari hubungan satu lawan satu.
‫Dan perbedaan antara banyak dan satu ton tentu
‫saja agak kabur tetapi pikirkan saja bahwa jika sesuatu dapat
‫tumbuh hampir tak terbatas maka itu pasti
‫hubungan satu banding satu.
‫Jadi sekali lagi, hubungan satu ke banyak
‫adalah yang paling penting untuk diketahui.
‫Ngomong-ngomong; dalam database
‫relasional hanya ada satu ke banyak
‫tanpa menghitung berapa banyak sebenarnya.
‫Dalam database MongoDB meskipun
‫itu adalah perbedaan yang sangat penting.
‫Karena itu salah satu faktor yang akan kita gunakan
‫untuk memutuskan apakah kita harus mendenormalisasi
‫atau menormalkan data seperti yang akan Anda pelajari nanti.
‫Bagaimanapun, jenis hubungan yang lebih sedikit adalah banyak ke banyak di
‫mana satu film dapat memiliki banyak aktor.
‫Tetapi pada saat yang sama satu aktor dapat bermain di banyak film.
‫Jadi di sini hubungan pada dasarnya
‫berjalan dua arah.
‫Dimana sebelumnya pada tipe yang
‫lain hanya satu arah.
‫Misalnya satu film dapat memiliki banyak ulasan tetapi satu yang
‫spesifik hanya untuk satu film itu. Benar.
‫Dan hal yang sama berlaku untuk penghargaan.
‫Jadi satu penghargaan khusus seperti untuk aktor
‫terbaik hanya diberikan pada satu film, bukan beberapa film.
‫Tapi dengan film dan aktor memang berbeda.
‫Jadi sekali lagi satu film dibintangi banyak aktor tetapi
‫satu aktor memainkan banyak film
‫dan begitu banyak hubungan banyak ke banyak.
‫Oke.
‫Jadi ingatlah semua ini saat kita bergerak maju dalam
‫kuliah ini.
‫Dan mungkin aspek terpenting yang perlu kita
‫pelajari tentang database MongoDB adalah mereferensikan dan
‫menyematkan dua kumpulan data.
‫Dan kami sebenarnya sudah membicarakan
‫sedikit tentang ini sebelumnya, tetapi mari kita tinjau
‫di sini dan masuk lebih dalam juga.
‫Jadi setiap kali kami memiliki dua
‫kumpulan data terkait, kami dapat mewakili data terkait itu
‫dalam bentuk referensi atau dinormalisasi atau dalam bentuk yang disematkan atau didenormalisasi.
‫Dan saya terus menggunakan dua istilah terkait bersama-sama
‫seperti referensi dan normalisasi karena
‫Anda akan melihat keduanya
‫digunakan dan penting bagi Anda untuk mengetahui semuanya.
‫Bagaimanapun, dalam formulir yang direferensikan, kami menyimpan dua kumpulan
‫data terkait dan semua dokumen terpisah.
‫Jadi sekali lagi semua data dipisahkan
‫dengan baik, itulah artinya dinormalisasi.
‫Jadi melanjutkan, contoh database film dari sebelumnya kita akan
‫memiliki satu dokumen film dan satu dokumen aktor
‫untuk setiap aktor. Sekarang bagaimana kita membuat hubungan
‫antara film dan aktor sehingga nanti di aplikasi kita, kita
‫dapat menunjukkan aktor mana yang bermain dalam film tertentu.
‫Karena jika mereka semua dokumen yang sama sekali berbeda, film tidak
‫memiliki cara untuk mengetahui tentang para aktor. Benar.
‫Nah di situlah ID masuk.
‫Jadi kami menggunakan ID aktor untuk membuat referensi pada
‫dokumen film.
‫Secara efektif menghubungkan film dengan aktor.
‫Jadi Anda melihat bahwa dalam dokumen film kami memiliki larik
‫tempat kami menyimpan ID semua aktor
‫sehingga ketika kami meminta data tentang film tertentu, kami dapat
‫dengan mudah mengidentifikasi aktornya. Apakah itu masuk akal?
‫Sekarang jenis referensi ini disebut referensi anak karena
‫induknya dalam hal ini film
‫yang merujuk anak-anaknya. Dalam hal ini para aktor.
‫Jadi kami benar-benar membuat semacam hierarki di sini. Benar.
‫Sekarang ada juga referensi orang tua dan
‫kita akan membicarakannya nanti.
‫Dan omong-omong dalam database relasional; semua data selalu
‫direpresentasikan dalam bentuk normal seperti ini.
‫Tetapi dalam database tanpa sekuel seperti MongoDB,
‫kita dapat mendenormalisasi data menjadi bentuk yang didenormalisasi
‫hanya dengan menyematkan dokumen
‫terkait langsung ke dokumen utama.
‫Jadi sekarang kami memiliki semua data
‫yang relevan tentang aktor di dalam satu dokumen film
‫utama tanpa memerlukan dokumen, koleksi, dan ID terpisah.
‫Jadi sekali lagi, jika kita memilih untuk mendenormalisasi atau menyematkan data kita,
‫kita akan memiliki satu dokumen utama yang berisi semua data utama
‫serta data terkait. Baiklah.
‫Dan hasilnya adalah aplikasi kita akan membutuhkan
‫lebih sedikit query ke database.
‫Karena kita bisa
‫mendapatkan semua data tentang film dan
‫aktor sekaligus yang tentunya akan meningkatkan performa kita.
‫Sekarang kelemahannya di sini adalah
‫tentu saja kita tidak dapat benar-benar menanyakan data yang disematkan sendiri.
‫Jadi jika itu adalah persyaratan untuk aplikasi, Anda harus
‫memilih desain yang dinormalisasi dan karena kita berbicara
‫tentang pro dan kontra dari bentuk
‫yang dinormalisasi; mari kita lakukan hal yang
‫sama tentang desain yang dinormalisasi.
‫Dan pada dasarnya kebalikan dari apa yang
‫baru saja kita bicarakan.
‫Jadi ada peningkatan kinerja ketika
‫kita sering perlu meng-query data terkait itu sendiri karena kita
‫hanya bisa meng-query data yang kita butuhkan dan
‫tidak selalu film dan aktor bersama-sama.
‫Tetapi di sisi lain; ketika kita perlu benar-benar
‫menanyakan film dan aktor bersama-sama,
‫kita akan membutuhkan banyak pertanyaan ke database.
‫Jadi pertama-tama kueri untuk film dan kemudian dari sana kita
‫juga akan membutuhkan kueri untuk aktor dan
‫itu tentu saja berfungsi untuk kinerja.
‫Jadi saat mendesain database Anda; ini adalah jenis hal yang
‫perlu Anda ingat. Baiklah.
‫Dan sekarang hanya sebagai catatan tambahan; kita tentu saja dapat memulai proses
‫berpikir kita dengan data yang didenormalisasi
‫dan kemudian sampai pada kesimpulan bahwa yang terbaik
‫adalah benar-benar menormalkan data.
‫Jadi ketika memikirkan model data kami, cara mengatur
‫data ini bekerja dengan dua cara.
‫Sekarang, bagaimana kita benar-benar memutuskan apakah kita harus
‫menormalkan atau mendenormalisasi data?
‫Nah itulah yang akan kita pelajari selanjutnya.
‫Jadi ketika kita memiliki dua dataset terkait; kita harus memutuskan
‫apakah kita akan menyematkan kumpulan data atau apakah kita akan
‫memisahkannya dan merujuknya
‫dari satu kumpulan data ke kumpulan data lainnya.
‫Dan saya mengembangkan kerangka keputusan ini yang
‫akan saya tunjukkan kepada Anda di mana kami menggunakan tiga
‫kriteria untuk mengambil keputusan itu.
‫Pertama kita melihat jenis hubungan yang
‫ada di antara kumpulan data.
‫Kedua, kami mencoba menentukan pola akses
‫data dari kumpulan data yang ingin kami sematkan atau referensikan.
‫Dan ini hanya berarti menganalisis seberapa sering data dibaca dan
‫ditulis dalam kumpulan data itu.
‫Kemudian kita juga melihat sesuatu yang saya sebut kedekatan data.
‫Dan kedekatan data adalah istilah yang sebenarnya baru saja saya
‫buat tetapi yang dimaksud adalah seberapa banyak data yang benar-benar terkait
‫dan bagaimana kita ingin meng-query data dari database.
‫Dan ini akan lebih
‫masuk akal ketika kita membicarakannya sebentar lagi.
‫Sekarang untuk benar-benar mengambil keputusan; kita perlu menggabungkan
‫ketiga kriteria ini dan
‫tidak hanya menggunakan salah satunya secara terpisah.
‫Jadi misalnya; Hanya karena kriteria nomor satu mengatakan
‫untuk menyematkan bukan berarti kita tidak perlu
‫melihat dua kriteria lainnya.
‫Baiklah dan mari kita mulai dengan tipe hubungan.
‫Jadi biasanya ketika kita memiliki hubungan satu ke beberapa kita
‫akan selalu menyematkan dataset terkait ke dalam
‫dataset utama seperti yang kita pelajari di
‫slide terakhir. Benar.
‫Sekarang dalam hubungan satu ke banyak; hal-hal
‫sedikit lebih kabur jadi tidak apa-apa untuk menanamkan atau referensi.
‫Dalam hal ini kita harus memutuskan
‫sesuai dengan dua kriteria lainnya.
‫Sekarang di sisi lain, pada satu
‫ke satu ton atau banyak ke banyak hubungan kita biasanya
‫selalu referensi data. Itu karena jika kita benar-benar
‫melakukan embed dalam kasus ini kita bisa dengan cepat membuat dokumen yang terlalu besar.
‫Bahkan berpotensi melebihi maksimal 16 megabyte.
‫Jadi solusi untuk itu tentu saja merujuk
‫atau menormalkan data. Dan sebagai contoh cepat;
‫katakanlah dalam contoh database film kami,
‫kami memiliki sekitar 100 gambar yang terkait dengan setiap film.
‫Jadi kita bisa mengatakan ini adalah hubungan satu
‫ke banyak tetapi apakah kita akan menyematkan dataset atau haruskah
‫kita merujuknya di sini. Yah kita tidak benar-benar tahu.
‫Jadi mari kita lihat dua kriteria lainnya.
‫Jadi yang kedua adalah tentang pola akses data di mana
‫itu hanya deskripsi mewah
‫untuk mengevaluasi apakah kumpulan data
‫tertentu sebagian besar ditulis atau sebagian besar dibaca.
‫Jadi, jika kumpulan data yang kita putuskan kebanyakan dibaca dan
‫datanya tidak banyak diperbarui,
‫maka kita mungkin harus menyematkan kumpulan data itu.
‫Jadi rasio baca/tulis yang tinggi hanya berarti bahwa
‫ada lebih banyak membaca daripada menulis.
‫Dan sekali lagi, kumpulan data seperti itu adalah kandidat yang baik
‫untuk disematkan.
‫Alasan untuk ini adalah bahwa dengan menyematkan kita hanya perlu
‫satu perjalanan ke database per kueri.
‫Sedangkan untuk referensi kita membutuhkan dua perjalanan. Benar.
‫Jadi jika kita menyematkan data yang banyak dibaca;
‫di setiap kueri, kami menyimpan satu
‫perjalanan ke database yang membuat seluruh proses lebih berkinerja.
‫Jadi saya pikir contoh gambar film kita sebenarnya
‫akan menjadi kandidat yang baik untuk disematkan.
‫Karena setelah 100 gambar disimpan ke database,
‫mereka tidak benar-benar diperbarui lagi
‫karena sebenarnya tidak ada yang perlu diperbarui
‫tentang suatu gambar. Benar, jadi ini
‫semua tentang membaca dan karena itu berdasarkan
‫kriteria ini kami akan menyematkan dokumen yang dicitrakan.
‫Sekarang di sisi lain, jika data kita banyak
‫diperbarui maka kita harus mempertimbangkan untuk mereferensikan atau menormalkan data.
‫Itu karena lebih banyak pekerjaan untuk mesin database untuk
‫memperbarui dan menyematkan dokumen
‫daripada dokumen mandiri yang lebih sederhana.
‫Dan karena tujuan utama kami adalah kinerja;
‫kami hanya menormalkan dataset.
‫Dalam contoh kami, katakanlah setiap film memiliki banyak ulasan dan
‫setiap ulasan dapat ditandai sebagai bermanfaat oleh pengguna.
‫Jadi setiap kali seseorang mengklik ulasan ini sangat membantu dalam
‫aplikasi kami. Kami
‫perlu memperbarui dokumen terkait.
‫Dan ini berarti bahwa data dapat berubah sepanjang
‫waktu dan ini adalah kandidat yang bagus untuk normalisasi.
‫Sekali lagi karena kami tidak ingin selalu
‫menanyakan film jika yang benar-benar ingin kami perbarui adalah ulasan
‫dengan menandainya sebagai bermanfaat.
‫Oke, apakah itu masuk akal?
‫Dan terakhir kriteria terakhir yang saya sebut kedekatan data;
‫yang seperti ukuran untuk seberapa banyak
‫data terkait. Jadi, jika dua
‫set data benar-benar dimiliki bersama, maka mereka
‫mungkin harus disematkan satu sama lain.
‫Dalam contoh kita; semua pengguna dapat memiliki banyak alamat email
‫di akun mereka dan karena mereka secara
‫intrinsik terhubung dengan pengguna, tidak diragukan lagi email
‫harus disematkan ke dalam dokumen.
‫Sekarang jika kita sering perlu mengkueri kedua kumpulan data sendiri,
‫maka itu adalah alasan yang sangat
‫baik untuk menormalkan data menjadi dua kumpulan data terpisah.
‫Bahkan jika mereka terkait erat.
‫Jadi bayangkan bahwa di aplikasi
‫kami, kami memiliki kuis di mana pengguna harus mengidentifikasi film berdasarkan gambar.
‫Ini berarti bahwa kita akan meminta banyak
‫gambar sendiri.
‫Jadi tanpa harus menanyakan film itu sendiri.
‫Jadi jika kita menerapkan kriteria ketiga ini;
‫kami sampai pada kesimpulan bahwa kami harus benar-benar menormalkan
‫dataset gambar. Baiklah.
‫Karena sekali lagi jika kita menerapkan fungsi kuis ini;
‫gambar akan ditanyai sendiri sepanjang waktu.
‫Jadi, semua ini menunjukkan bahwa kita harus benar-benar
‫melihat ketiga kriteria tersebut bersama-sama
‫daripada hanya satu dari mereka secara terpisah.
‫Karena hal itu dapat mengakibatkan keputusan yang kurang optimal.
‫Dan saya katakan kurang optimal bukannya
‫salah karena tidak sepenuhnya benar
‫atau sepenuhnya salah cara memodelkan data kita.
‫Tidak ada aturan yang sulit; ini seperti panduan yang dapat
‫Anda ikuti untuk menemukan cara
‫yang paling benar dalam menyusun data Anda.
‫Tapi sekali lagi, sulit untuk benar-benar salah.
‫Oke?
‫Sekarang, katakanlah kita telah memilih untuk menormalkan
‫dataset kita.
‫Jadi dengan kata lain untuk referensi data.
‫Kemudian setelah itu kita masih harus
‫memilih di antara tiga jenis referensi yang berbeda.
‫Referensi anak, referensi orang tua, dan
‫referensi dua arah.
‫Jadi tipe pertama adalah referensi anak.
‫Yang merupakan tipe referensi yang sebenarnya saya tunjukkan sebelumnya.
‫Oke?
‫Dan jangan mengambil contoh kesalahan logging yang
‫saya sebutkan sebelumnya. Di mana
‫kita berpotensi memiliki jutaan dokumen yang terkunci.
‫Jadi dalam referensi anak; kami pada dasarnya menyimpan referensi ke
‫dokumen anak terkait dalam dokumen induk.
‫Dan mereka biasanya disimpan dalam array.
‫Jadi Anda melihat bahwa setiap log memiliki ID
‫dan kemudian di dokumen aplikasi ada larik dengan semua
‫ID ini. Benar?
‫Namun, masalahnya di sini adalah array
‫ID ini bisa menjadi sangat besar jika ada banyak anak.
‫Dan ini adalah anti-pola di MongoDB.
‫Jadi sesuatu yang kita harus menghindari di semua biaya.
‫Juga, referensi anak membuat
‫orang tua dan anak menjadi sangat erat.
‫Yang tidak selalu ideal. Tapi itulah mengapa
‫kami memiliki referensi orang tua.
‫Jadi dalam referensi orang tua; itu benar-benar
‫bekerja sebaliknya.
‫Jadi di sini, di setiap dokumen anak, kami menyimpan
‫referensi ke elemen induk.
‫Oleh karena itu referensi nama orang tua.
‫Dalam contoh ini ID aplikasi adalah 23 dan
‫di setiap log ada bidang aplikasi
‫dengan 23 ID di dalamnya.
‫Agar anak selalu mengenal orang tuanya.
‫Jadi dalam hal ini orang tua sebenarnya tidak tahu
‫apa-apa tentang anak-anak.
‫Bukan siapa mereka dan bukan berapa banyak mereka.
‫Jadi, mereka jauh lebih terisolasi dan lebih mandiri.
‫Dalam hal itu, terkadang bisa bermanfaat.
‫Jadi mana dari kedua jenis ini yang sebenarnya lebih baik
‫untuk hubungan data ini.
‫Dan ingat bagaimana saya mengatakan bahwa
‫mungkin ada jutaan log dan jadi anggaplah ada dua
‫juta dokumen yang dicatat.
‫Dalam kasus referensi anak, itu berarti ada
‫dua juta referensi
‫ID dalam dokumen aplikasi.
‫Benar? Sekarang juga ingat bagaimana saya
‫mengatakan bahwa ada batas 16 megabyte pada dokumen.
‫Jadi jika kita terus menambahkan dan menambahkan ID anak ini ke
‫dalam larik pada induknya; maka kita akan
‫dengan cepat mencapai batas 16 megabyte yang dapat
‫ditampung oleh setiap dokumen Bson.
‫Hanya karena array itu akan tumbuh begitu banyak.
‫Jadi itu tidak akan berhasil.
‫Apakah itu?
‫Di sisi lain dengan referensi
‫orang tua masalah itu tidak akan terjadi.
‫Kami hanya akan memiliki dua
‫juta dokumen terkunci seperti sebelumnya tetapi masing-masing memegang ID induknya.
‫Tetapi tidak ada array yang akan
‫tumbuh tanpa batas dan oleh karena itu referensi
‫orang tua akan menjadi solusi terbaik di sini.
‫Jadi kesimpulan dari semua ini adalah bahwa secara
‫umum referensi anak paling baik digunakan untuk
‫satu atau beberapa hubungan. Di mana kita tahu
‫sebelumnya bahwa susunan dokumen anak tidak akan bertambah banyak.
‫Di sisi lain, referensi orang tua paling baik digunakan
‫untuk hubungan satu ke banyak dan satu ke satu ton
‫seperti ini. Oke?
‫Jadi sekali lagi, selalu ingat bahwa salah satu
‫prinsip terpenting dari pemodelan data MongoDB
‫adalah bahwa array tidak boleh dibiarkan tumbuh tanpa batas.
‫Agar tidak pernah melanggar batas 16 megabyte itu.
‫Kami juga tidak ingin mengirimi pengguna kami
‫array dengan ribuan ID setiap kali mereka
‫meminta kumpulan data induk. Oke?
‫Jadi, apakah logika ini masuk akal bagi Anda?
‫Kemudian mari kita beralih ke jenis referensi ketiga
‫yang merupakan referensi dua arah.
‫Dan kali ini dengan contoh film dan aktor yang
‫saya tunjukkan kepada Anda ketika kita berbicara
‫tentang banyak ke banyak hubungan. Ingat itu?
‫Jadi sekali lagi, setiap film memiliki banyak aktor
‫dan setiap aktor bermain di banyak film.
‫Dan itulah tipikal hubungan banyak ke banyak.
‫Dan kami biasanya menggunakan referensi dua arah ini untuk
‫merancang banyak hubungan. Dan itu bekerja
‫seperti ini; di setiap film kami akan menyimpan referensi ke
‫semua aktor yang membintangi film itu. Jadi agak seperti di referensi anak.
‫Namun dan pada saat yang sama di setiap
‫aktor kami juga menyimpan referensi ke semua
‫film yang dimainkan aktor tersebut.
‫Jadi film dan aktor terhubung di kedua arah.
‫Oleh karena itu nama referensi dua arah.
‫Dan ini membuatnya sangat
‫mudah untuk mencari film dan aktor sepenuhnya secara mandiri.
‫Sementara juga memudahkan untuk menemukan aktor yang
‫terkait dengan setiap film dan film yang terkait
‫dengan masing-masing aktor.
‫(napas dalam-dalam)
‫Ini memang kuliah yang cukup panjang.
‫Dengan banyak konsep dan prinsip dan pedoman
‫baru yang perlu diingat.
‫Jadi untuk membantu Anda dengan itu; inilah ringkasan
‫singkat dan beberapa panduan umum yang dapat Anda
‫lihat saat Anda membutuhkannya.
‫Jadi prinsip yang paling penting adalah: susun data Anda
‫agar sesuai dengan cara aplikasi Anda menanyakan dan
‫memperbarui data.
‫Atau dengan kata lain: identifikasi pertanyaan yang muncul dari kasus
‫penggunaan aplikasi Anda terlebih dahulu, lalu
‫modelkan data Anda sehingga pertanyaan dapat dijawab
‫dengan cara yang paling efisien.
‫Sebagai contoh; ketika saya perlu menanyakan film dan aktor selalu
‫bersama atau apakah ada skenario di mana saya hanya menanyakan
‫film atau hanya aktor.
‫Pertanyaan semacam itu akan menjadi
‫dasar model data Anda.
‫Secara umum, selalu pilih penyematan kecuali ada alasan bagus
‫untuk tidak menyematkan.
‫Terutama pada hubungan satu ke beberapa dan satu ke banyak.
‫Selanjutnya, hubungan satu ke satu atau banyak ke banyak biasanya
‫merupakan alasan yang baik untuk referensi alih-alih menyematkan.
‫Juga, pilih referensi ketika data banyak diperbarui
‫dan jika Anda perlu sering mengakses kumpulan data sendiri.
‫Gunakan penyematan saat data sebagian besar dibaca tetapi jarang diperbarui dan
‫saat dua set data secara intrinsik menyatu.
‫Jangan biarkan array tumbuh tanpa batas.
‫Karena itu, jika Anda ingin menormalkan; gunakan referensi anak
‫untuk hubungan satu ke banyak dan referensi orang tua untuk
‫hubungan satu ke satu ton.
‫Dan akhirnya gunakan referensi dua arah
‫untuk banyak hubungan.
‫Baiklah?
‫Dan itu cukup banyak meringkasnya.
‫Saya benar-benar akan merekomendasikan Anda menonton video ini
‫dua kali jika Anda bisa, hanya karena betapa pentingnya
‫materi ini sebenarnya. Baiklah?
‫Pokoknya sampai jumpa di video selanjutnya.