Saya baru saja mulai dengan DB non-relasional, dan saya masih mencoba memahami dan mencari tahu model terbaik apa yang akan saya buat. Dan saya hanya dapat berbicara untuk CouchDB.
Namun, saya memiliki beberapa kesimpulan awal:
Sudahkah Anda menemukan desain alternatif yang bekerja jauh lebih baik di dunia non-relasional?
Fokus desain bergeser: Desain model dokumen (sesuai dengan tabel DB) menjadi hampir tidak relevan, sementara semuanya bergantung pada desain tampilan (sesuai dengan kueri).
Jenis DB dokumen menukar kerumitan: SQL memiliki data yang tidak fleksibel dan permintaan yang fleksibel, DB dokumen adalah sebaliknya.
Model CouchDB adalah kumpulan "dokumen JSON" (pada dasarnya tabel hash bersarang). Setiap dokumen memiliki ID unik, dan bisa diambil dengan mudah menggunakan ID. Untuk kueri lainnya, Anda menulis "tampilan", yang dinamai kumpulan fungsi peta / pengurangan. Tampilan mengembalikan hasil yang ditetapkan sebagai daftar pasangan kunci / nilai.
Triknya adalah Anda tidak membuat kueri database dalam arti Anda membuat kueri database SQL: Hasil menjalankan fungsi tampilan disimpan dalam indeks, dan hanya indeks yang dapat ditanyai. (Seperti "get everything", "get key" atau "get key range".)
Analogi terdekat di dunia SQL adalah jika Anda hanya dapat melakukan kueri DB menggunakan prosedur tersimpan - setiap kueri yang ingin Anda dukung harus ditentukan sebelumnya.
Desain dokumen sangat fleksibel. Saya hanya menemukan dua kendala:
- Simpan data terkait bersama dalam dokumen yang sama, karena tidak ada yang terkait dengan gabungan.
- Jangan membuat dokumen terlalu besar sehingga terlalu sering diperbarui (seperti memasukkan semua penjualan perusahaan untuk tahun ini dalam dokumen yang sama), karena setiap pembaruan dokumen memicu pengindeksan ulang.
Tapi semuanya bergantung pada mendesain tampilan.
Desain alternatif yang saya temukan bahwa urutan kerja yang lebih baik dengan CouchDB daripada database SQL mana pun berada pada level sistem daripada level penyimpanan. Jika Anda memiliki beberapa data dan ingin menyajikannya ke halaman web, kompleksitas sistem total berkurang setidaknya 50%:
- tidak merancang tabel DB (masalah kecil)
- tidak ada lapisan perantara ODBC / JDBC, semua pertanyaan dan transaksi melalui http (masalah sedang)
- pemetaan DB-to-object sederhana dari JSON, yang hampir sepele dibandingkan dengan yang sama di SQL (penting!)
- Anda berpotensi melewatkan seluruh server aplikasi, karena Anda dapat merancang dokumen Anda untuk diambil langsung oleh browser menggunakan AJAX dan menambahkan sedikit pemolesan JavaScript sebelum ditampilkan sebagai HTML. (BESAR !!)
Untuk aplikasi web normal, DB berbasis dokumen / JSON adalah keuntungan besar, dan kekurangan dari kueri yang kurang fleksibel dan beberapa kode tambahan untuk validasi data tampaknya merupakan harga yang harus dibayar.
Sudahkah kepala Anda terbentur sesuatu yang tampaknya mustahil?
Belum. Map / reduce sebagai cara untuk membuat kueri database masih asing, dan membutuhkan lebih banyak pemikiran daripada menulis SQL. Ada sejumlah kecil primitif, jadi mendapatkan hasil yang Anda butuhkan pada dasarnya adalah pertanyaan tentang menjadi kreatif dengan cara Anda menentukan kuncinya.
Ada batasan di mana kueri tidak dapat melihat dua dokumen atau lebih pada saat yang sama - tidak ada gabungan atau jenis hubungan multi-dokumen lainnya, tetapi sejauh ini tidak ada yang tidak dapat diatasi.
Sebagai contoh batasan, penghitungan dan penjumlahan mudah tetapi rata-rata tidak dapat dihitung dengan tampilan / kueri CouchDB. Fix: Kembalikan jumlah dan hitung secara terpisah dan hitung rata-rata pada klien.
Sudahkah Anda menjembatani kesenjangan dengan pola desain apa pun, misalnya menerjemahkan dari satu pola ke pola lainnya?
Saya tidak yakin itu layak. Ini lebih merupakan desain ulang yang lengkap, seperti menerjemahkan program gaya fungsional ke gaya berorientasi objek. Secara umum, jenis dokumen jauh lebih sedikit daripada tabel SQL dan lebih banyak data di setiap dokumen.
Salah satu cara untuk memikirkannya adalah dengan melihat SQL Anda untuk penyisipan dan kueri umum: Tabel dan kolom mana yang diperbarui ketika pelanggan melakukan pemesanan, misalnya? Dan yang mana untuk laporan penjualan bulanan? Info itu mungkin harus masuk dalam dokumen yang sama.
Yaitu: Satu dokumen untuk Pesanan, berisi ID pelanggan dan ID produk, dengan bidang yang direplikasi seperlunya untuk menyederhanakan kueri. Apa pun di dalam dokumen dapat ditanyakan dengan mudah, apa pun yang membutuhkan referensi silang antara mengatakan Order dan Pelanggan harus dilakukan oleh klien. Jadi jika Anda ingin laporan penjualan menurut wilayah, Anda mungkin harus memasukkan kode wilayah ke dalam pesanan.
Apakah Anda bahkan melakukan model data eksplisit sama sekali sekarang (misalnya dalam UML)?
Maaf, tidak pernah melakukan banyak UML sebelum DB dokumen :)
Tetapi Anda memerlukan semacam model yang mengatakan bidang mana yang termasuk dalam dokumen mana dan jenis nilai apa yang dikandungnya. Baik untuk referensi Anda sendiri nanti dan untuk memastikan bahwa setiap orang yang menggunakan DB mengetahui konvensi. Karena Anda tidak lagi mendapatkan kesalahan jika Anda menyimpan tanggal di bidang teks, misalnya, dan siapa pun dapat menambah atau menghapus bidang apa pun yang mereka sukai, Anda memerlukan kode validasi dan konvensi untuk mengatasi kekosongan. Terutama jika Anda bekerja dengan sumber daya eksternal.
Apakah Anda melewatkan salah satu layanan tambahan utama yang disediakan RDBMS?
Nggak. Tapi latar belakang saya adalah pengembang aplikasi web, kami berurusan dengan database hanya sejauh yang kami harus :)
Perusahaan tempat saya bekerja membuat produk (webapp) yang dirancang untuk dijalankan di database SQL dari beberapa vendor, dan "layanan tambahan" sangat berbeda dari DB ke DB sehingga harus diimplementasikan secara terpisah untuk setiap DB. Jadi, lebih sedikit pekerjaan bagi kami untuk memindahkan fungsionalitas dari RDBMS. Ini bahkan meluas ke pencarian teks lengkap.
Jadi apa pun yang saya serahkan adalah sesuatu yang tidak pernah benar-benar saya miliki. Jelas sekali, pengalaman Anda mungkin berbeda.
Peringatan: Yang saya kerjakan sekarang adalah aplikasi web untuk data keuangan, harga saham, dan sejenisnya. Ini sangat cocok untuk DB dokumen, dari sudut pandang saya, saya mendapatkan semua manfaat dari DB (ketekunan dan kueri) tanpa kerumitan.
Tetapi data ini cukup independen satu sama lain, tidak ada kueri relasional yang kompleks. Dapatkan penawaran harga terbaru berdasarkan ticker, dapatkan penawaran harga berdasarkan ticker dan rentang tanggal, dapatkan info meta perusahaan, itu saja. Contoh lain yang saya lihat adalah aplikasi blog, dan blog juga tidak dicirikan oleh skema database yang sangat rumit.
Apa yang ingin saya katakan adalah bahwa semua aplikasi DB dokumen yang berhasil yang saya ketahui memiliki data yang tidak memiliki banyak keterkaitan di tempat pertama: Dokumen (seperti dalam pencarian Google), posting blog, artikel berita, data keuangan .
Saya berharap ada kumpulan data yang memetakan lebih baik ke SQL daripada ke model dokumen, jadi menurut saya SQL akan bertahan.
Tetapi bagi kita yang hanya menginginkan cara sederhana untuk menyimpan dan mengambil data - dan saya menduga ada banyak dari kita - database dokumen (seperti di CouchDB) adalah anugerah.