Saya baru saja menemukan pertanyaan ini dan, meskipun sudah lama, saya pikir akan bermanfaat untuk menambahkan beberapa kemungkinan yang tidak disebutkan dalam jawaban yang diberikan. Selain itu, beberapa hal telah bergerak sedikit dalam beberapa tahun terakhir, jadi perlu ditekankan bahwa SQL dan NoSQL bergerak lebih dekat satu sama lain.
Salah satu komentator mengemukakan sikap berhati-hati yang bijaksana bahwa "jika data bersifat relasional, gunakan relasional". Namun, komentar itu hanya masuk akal di dunia relasional, di mana skema selalu datang sebelum aplikasi.
DUNIA HUBUNGAN: Data struktur> Tulis aplikasi untuk mendapatkannya
NOSQL DUNIA: Desain aplikasi> Data struktur sesuai
Sekalipun data bersifat relasional, NoSQL masih merupakan opsi. Misalnya, hubungan satu-ke-banyak tidak ada masalah sama sekali dan secara luas dibahas dalam dokumen MongoDB
SOLUSI 2015 UNTUK MASALAH 2010
Sejak pertanyaan ini diposting, ada upaya serius untuk membawa noSQL lebih dekat ke SQL. Tim yang dipimpin oleh Yannis Papakonstantinou di University of California (San Diego) telah mengerjakan FORWARD , sebuah implementasi dari SQL ++ yang dapat segera menjadi solusi untuk masalah yang terus-menerus seperti yang diposting di sini.
Pada tingkat yang lebih praktis, rilis Couchbase 4.0 berarti bahwa, untuk pertama kalinya, Anda dapat melakukan JOIN asli di NoSQL. Mereka menggunakan N1QL mereka sendiri. Ini adalah contoh dari JOINdari tutorial mereka :
SELECT usr.personal_details, orders
FROM users_with_orders usr
USE KEYS "Elinor_33313792"
JOIN orders_with_users orders
ON KEYS ARRAY s.order_id FOR s IN usr.shipped_order_history END
N1QL memungkinkan untuk sebagian besar jika tidak semua operasi SQL termasuk penggabungan, penyaringan, dll.
SOLUSI HYBRID BUKAN-SANGAT BARU
Jika MongoDB masih merupakan satu-satunya pilihan, maka saya ingin kembali ke poin saya bahwa aplikasi harus didahulukan dari struktur data. Tidak ada jawaban yang menyebutkan hybrid embedding, di mana sebagian besar data yang dipertanyakan tertanam dalam dokumen / objek, dan referensi disimpan untuk sebagian kecil kasus.
Contoh: dapatkah informasi (selain nama peran) menunggu? dapatkah bootstrap aplikasi lebih cepat dengan tidak meminta apa pun yang belum dibutuhkan pengguna?
Ini bisa menjadi kasus jika pengguna login dan dia perlu melihat semua opsi untuk semua perannya. Namun, pengguna adalah "Insinyur" dan opsi untuk peran ini jarang digunakan. Ini berarti aplikasi hanya perlu menunjukkan opsi untuk seorang insinyur jika dia ingin mengkliknya.
Ini dapat dicapai dengan dokumen yang memberi tahu aplikasi pada awal (1) peran apa yang menjadi milik pengguna dan (2) di mana mendapatkan informasi tentang suatu peristiwa yang terkait dengan peran tertentu.
{_id: ObjectID(),
roles: [[“Engineer”, “ObjectId()”],
[“Administrator”, “ObjectId()”]]
}
Atau, bahkan lebih baik, indeks bidang role.name di kumpulan peran, dan Anda mungkin tidak perlu menanamkan ObjectID () juga.
Contoh lain: apakah informasi tentang SEMUA peran yang diminta SEMUA waktu?
Ini juga bisa menjadi kasus bahwa pengguna masuk ke dasbor dan 90% dari waktu melakukan tugas yang terkait dengan peran "Insinyur". Embedding hibrida dapat dilakukan untuk peran tertentu secara penuh dan menyimpan referensi untuk sisanya saja.
{_id: ObjectID(),
roles: [{name: “Engineer”,
property1: value1,
property2: value2
},
[“Administrator”, “ObjectId()”]
]
}
Menjadi schemaless bukan hanya karakteristik NoSQL, itu bisa menjadi keuntungan dalam hal ini. Ini benar-benar valid untuk menyarangkan berbagai jenis objek di properti "Peran" objek pengguna.