MongoDB tidak sesuai untuk urus niaga kukuh senario, tetapi banyak senario selalunya tidak memerlukan transaksi yang kukuh, dan boleh digantikan dengan konsistensi akhirnya. Banyak urus niaga yang kukuh juga boleh ditukar kepada keatomitian dokumen MongoDB melalui teknik penetapan model data untuk mengelakkan transaksi yang kukuh. Anda perlu menerangkan dengan lebih jelas jenis situasi yang anda bincangkan supaya anda boleh menilai sama ada ia boleh dielakkan. Untuk senario tempahan kursus yang saya faham, ia bukanlah senario kuat yang memerlukan MongoDB, tetapi ia bukan senario yang memerlukan RDBMS. Jadi untuk mengatakan sama ada MongoDB sesuai untuk digunakan, adalah disyorkan untuk menganalisis situasi tertentu secara terperinci. === Dikemas kini pada 2017.4.9 === Berdasarkan kemas kini dalam ulasan, penjelasan tambahan berikut dibuat: Keperluan untuk mengehadkan bilangan orang boleh diselesaikan menggunakan atomicity dokumen MongoDB . Setakat yang saya faham senario pendaftaran, ia tidak lebih daripada merekodkan siapa yang telah mendaftar kursus mana, jumlah orang yang telah mendaftar, dan mengawal untuk tidak melebihi had pendaftaran. Kemudian struktur data kursus boleh direka bentuk seperti ini:
Maksudnya, cari kursus ini mengikut ID kursus Jika bilangan pemohon kurang daripada nombor yang ditetapkan, pemohon baharu akan ditambah, jika tidak tiada perubahan akan dibuat. Jadi bagaimana untuk menilai sama ada pendaftaran berjaya? findAndModifySecara lalai, dokumen sebelum pengubahsuaian akan dikembalikan (dokumen selepas pengubahsuaian juga boleh dikembalikan). Jadi:
Untuk penggunaan findAndModify, sila rujuk db.collection.findAndModify(). Pengubahsuaian pada dokumen dalam MongoDB adalah atom, jadi tidak sukar untuk mencari bahawa update juga boleh menyelesaikan tugasan di atas dengan baik. Untuk perbandingan antara update dan findAndUpdate, sila rujuk: Bandingkan dengan Kaedah kemas kini
MongoDB tidak sesuai untuk urus niaga kukuh senario, tetapi banyak senario selalunya tidak memerlukan transaksi yang kukuh, dan boleh digantikan dengan konsistensi akhirnya. Banyak urus niaga yang kukuh juga boleh ditukar kepada keatomitian dokumen MongoDB melalui teknik penetapan model data untuk mengelakkan transaksi yang kukuh. Anda perlu menerangkan dengan lebih jelas jenis situasi yang anda bincangkan supaya anda boleh menilai sama ada ia boleh dielakkan.
Untuk senario tempahan kursus yang saya faham, ia bukanlah senario kuat yang memerlukan MongoDB, tetapi ia bukan senario yang memerlukan RDBMS. Jadi untuk mengatakan sama ada MongoDB sesuai untuk digunakan, adalah disyorkan untuk menganalisis situasi tertentu secara terperinci.
=== Dikemas kini pada 2017.4.9 ===
Berdasarkan kemas kini dalam ulasan, penjelasan tambahan berikut dibuat:
Keperluan untuk mengehadkan bilangan orang boleh diselesaikan menggunakan atomicity dokumen MongoDB . Setakat yang saya faham senario pendaftaran, ia tidak lebih daripada merekodkan siapa yang telah mendaftar kursus mana, jumlah orang yang telah mendaftar, dan mengawal untuk tidak melebihi had pendaftaran. Kemudian struktur data kursus boleh direka bentuk seperti ini:
Kursus ini boleh dikemas kini apabila seseorang mendaftar:
Maksudnya, cari kursus ini mengikut ID kursus Jika bilangan pemohon kurang daripada nombor yang ditetapkan, pemohon baharu akan ditambah, jika tidak tiada perubahan akan dibuat. Jadi bagaimana untuk menilai sama ada pendaftaran berjaya?
findAndModify
Secara lalai, dokumen sebelum pengubahsuaian akan dikembalikan (dokumen selepas pengubahsuaian juga boleh dikembalikan). Jadi:Untuk penggunaan
findAndModify
, sila rujuk db.collection.findAndModify(). Pengubahsuaian pada dokumen dalam MongoDB adalah atom, jadi tidak sukar untuk mencari bahawaupdate
juga boleh menyelesaikan tugasan di atas dengan baik. Untuk perbandingan antaraupdate
danfindAndUpdate
, sila rujuk: Bandingkan dengan Kaedah kemas kini