SQL vs NOSQL: Cara Memilih

3

Takeaways Key

• Pangkalan data SQL sangat sesuai untuk projek-projek dengan keperluan data yang berkaitan dengan baik dan di mana integriti data adalah kritikal. Mereka sering digunakan untuk kedai dalam talian dan sistem perbankan. Pangkalan data NoSQL lebih sesuai untuk projek -projek dengan keperluan data yang tidak berkaitan, berkembang atau tidak pasti, di mana kelajuan dan skalabiliti adalah kunci. Mereka biasanya digunakan untuk rangkaian sosial, pengurusan pelanggan dan sistem analisis web.
• pangkalan data NoSQL menawarkan fleksibiliti dalam penyimpanan data, yang membolehkan penambahan atau penyingkiran medan pada kehendak. Mereka menyimpan semua data mengenai individu dalam satu dokumen, membuat pengambilan data dan carian teks penuh lebih mudah. Walau bagaimanapun, mereka tidak melaksanakan peraturan integriti data atau urus niaga sokongan merentasi pelbagai dokumen.
• Pangkalan data SQL diperlukan untuk projek yang memerlukan integriti data dan sokongan transaksi yang mantap, seperti sistem pengurusan gudang. Mereka menyimpan data yang berkaitan dalam jadual, memerlukan skema sebelum digunakan, dan jadual sokongan bergabung. Walau bagaimanapun, skema itu tegar dan data boleh menjadi terfragmentasi, menjadikannya mencabar bagi pemaju atau pentadbir sistem untuk memeriksa pangkalan data.

Dalam artikel sebelumnya, kami membincangkan perbezaan utama antara pangkalan data SQL dan NoSQL. Dalam susulan ini, kami akan menggunakan pengetahuan kami untuk senario tertentu dan menentukan pilihan terbaik. Untuk merakam: Pangkalan Data SQL:

• menyimpan data berkaitan dalam jadual
• memerlukan skema yang mentakrifkan jadual sebelum menggunakan
• menggalakkan normalisasi untuk mengurangkan redundansi data
• Jadual Sokongan bergabung untuk mendapatkan data yang berkaitan dari pelbagai jadual dalam satu arahan
• Melaksanakan Peraturan Integriti Data
• menyediakan urus niaga untuk menjamin dua atau lebih kemas kini berjaya atau gagal sebagai unit atom
• boleh diperkuat (dengan usaha beberapa)
• Gunakan bahasa deklaratif yang kuat untuk pertanyaan
• menawarkan banyak sokongan, kepakaran dan alat.

Pangkalan Data NOSQL:

• Simpan data berkaitan dalam dokumen nilai-nama, nilai nama
• boleh menyimpan data tanpa menentukan skema
• biasanya mesti dinormalkan sehingga maklumat mengenai item terkandung dalam satu dokumen
• tidak sepatutnya memerlukan bergabung (menganggap dokumen denormalized digunakan)
• membenarkan sebarang data disimpan di mana -mana sahaja pada bila -bila masa tanpa pengesahan
• Kemas kini menjamin kepada satu dokumen - tetapi bukan beberapa dokumen
• menyediakan prestasi dan skalabiliti yang sangat baik
• Gunakan objek data JSON untuk pertanyaan
• adalah teknologi yang lebih baru dan menarik.

Pangkalan data SQL sangat sesuai untuk projek -projek di mana keperluan boleh ditentukan dan integriti data yang mantap adalah penting. Pangkalan data NoSQL adalah sesuai untuk keperluan data yang tidak berkaitan, tidak pasti atau berkembang di mana kelajuan dan skalabiliti lebih penting. Dalam istilah yang lebih mudah:

• SQL adalah digital. Ia berfungsi dengan baik untuk item yang jelas, diskret dengan spesifikasi yang tepat. Kes penggunaan biasa adalah kedai dalam talian dan sistem perbankan.
• NoSQL adalah analog. Ia berfungsi dengan baik untuk data organik dengan keperluan cecair. Kes penggunaan biasa adalah rangkaian sosial, pengurusan pelanggan dan sistem analisis web.

Beberapa projek akan sesuai. Sama ada pilihan boleh menjadi berdaya maju jika anda mempunyai data yang cetek atau secara semulajadi. Tetapi sila sedar senario contoh yang mudah ini dengan generalisasi menyapu! Anda tahu lebih banyak mengenai projek anda daripada yang saya lakukan, dan saya tidak akan mengesyorkan beralih dari SQL ke NoSQL atau sebaliknya kecuali ia menawarkan manfaat yang besar. Ini pilihan anda. Pertimbangkan kebaikan dan keburukan pada permulaan projek anda dan anda tidak boleh salah.

senario satu: senarai kenalan

Mari kita mencipta semula roda dan melaksanakan sistem buku alamat berasaskan SQL. Jadual hubungan naif awal kami ditakrifkan dengan medan berikut:

• id
• Tajuk
• firstName
• LastName
jantina
Telefon
e -mel
alamat1
alamat2
alamat3
• City
• rantau
• zipcode
• negara
Masalah Satu:

Beberapa orang mempunyai nombor telefon tunggal. Kami mungkin memerlukan sekurang-kurangnya tiga untuk talian tanah, mudah alih dan tempat kerja, tetapi tidak kira berapa banyak yang kita peruntukkan-seseorang, di suatu tempat akan mahu lebih banyak. Mari buat jadual telefon yang berasingan supaya kenalan boleh mempunyai seberapa banyak yang mereka suka. Ini juga menormalkan data kami - kami tidak memerlukan null untuk kenalan tanpa nombor: contact_id

• name
(teks seperti garis tanah, kerja mudah alih, dll.)
• nombor
Masalah Dua:

Kami mempunyai masalah yang sama dengan alamat e -mel, jadi mari buat jadual e -mel yang sama: contact_id

• name
(teks seperti e -mel rumah, e -mel kerja, dll.)
• Alamat
Masalah Tiga:

Kami mungkin tidak mahu memasukkan alamat (geografi), atau kami mungkin mahu memasukkan pelbagai alamat untuk kerja, rumah, rumah percutian, dan lain -lain. Oleh itu, kami memerlukan jadual alamat baru: contact_id

• name
(teks seperti rumah, pejabat, dll.)
• alamat1
• alamat2
• alamat3
City
rantau
zipcode
negara
Jadual hubungan asal kami telah dikurangkan kepada:
id

Tajuk
firstName
LastName
• jantina

Hebat - kami mempunyai pangkalan data yang dinormalisasi yang boleh menyimpan nombor nombor telefon, alamat e -mel dan alamat untuk sebarang kenalan. Malangnya… Skema itu tegar Kami tidak mempertimbangkan nama tengah hubungan, tarikh lahir, syarikat atau peranan pekerjaan. Tidak kira berapa banyak bidang yang kami tambah, kami akan menerima permintaan kemas kini untuk nota, ulang tahun, status hubungan, akaun media sosial, pengukuran kaki di dalam, jenis keju kegemaran dan lain -lain. Tidak mustahil untuk meramalkan setiap pilihan, jadi kami ' D mungkin membuat jadual lainData dengan pasangan nilai nama untuk mengatasi. Data itu berpecah belah Ia tidak mudah untuk pemaju atau pentadbir sistem untuk memeriksa pangkalan data. Logik program juga akan menjadi lebih perlahan dan lebih kompleks, kerana ia tidak praktikal untuk mendapatkan data hubungan dalam satu pernyataan pilih tunggal dengan pelbagai klausa menyertai. (anda boleh, tetapi hasilnya akan mengandungi setiap kombinasi telefon, e -mel dan alamat: Jika seseorang mempunyai tiga nombor telefon, lima e -mel dan dua alamat, pertanyaan SQL akan menghasilkan tiga puluh hasil.) Akhirnya, carian teks penuh adalah sukar. Jika seseorang memasuki rentetan "sitepoint" , kita mesti menyemak semua empat jadual untuk melihat sama ada ia adalah sebahagian daripada nama kenalan, telefon, e -mel atau alamat dan pangkat hasilnya dengan sewajarnya. Jika anda pernah menggunakan carian WordPress, anda akan memahami betapa mengecewakannya. Alternatif NoSQL

Data hubungan kami menyangkut orang. Mereka tidak dapat diramalkan dan mempunyai keperluan yang berbeza pada masa yang berlainan. Senarai kenalan akan mendapat manfaat daripada menggunakan pangkalan data NoSQL, yang menyimpan semua data mengenai individu dalam satu dokumen dalam koleksi kenalan:

Dalam contoh ini, kami tidak menyimpan tajuk atau jantina kenalan, dan kami telah menambah data yang tidak perlu digunakan untuk orang lain. Tidak penting - pangkalan data NoSQL kami tidak keberatan, dan kami boleh menambah atau mengeluarkan medan mengikut kehendak. Kerana data hubungan terkandung dalam satu dokumen, kami boleh mengambil beberapa atau semua maklumat menggunakan pertanyaan tunggal. Carian teks penuh juga lebih mudah; Di MongoDB kita dapat menentukan indeks pada semua hubungan medan teks menggunakan:

<span>{
</span>  <span>name: [
</span>    <span>"Billy", "Bob", "Jones"
</span>  <span>],
</span>  <span>company: "Fake Goods Corp",
</span>  <span>jobtitle: "Vice President of Data Management",
</span>  <span>telephone: {
</span>    <span>home: "0123456789",
</span>    <span>mobile: "9876543210",
</span>    <span>work: "2244668800"
</span>  <span>},
</span>  <span>email: {
</span>    <span>personal: "bob@myhomeemail.net",
</span>    <span>work: "bob@myworkemail.com"
</span>  <span>},
</span>  <span>address: {
</span>    <span>home: {
</span>      <span>line1: "10 Non-Existent Street",
</span>      <span>city: "Nowhere",
</span>      <span>country: "Australia"
</span>    <span>}
</span>  <span>},
</span>  <span>birthdate: <span>ISODate</span>("1980-01-01T00:00:00.000Z"),
</span>  <span>twitter: '@bobsfakeaccount',
</span>  <span>note: "Don't trust this guy",
</span>  <span>weight: "200lb",
</span>  <span>photo: "52e86ad749e0b817d25c8892.jpg"
</span><span>}</span>

Kemudian lakukan carian teks penuh menggunakan:

db<span>.contact.createIndex({ "$**": "text" });</span>

db<span>.contact.find({
</span>  <span>$text: { $search: "something" }
</span><span>});</span>

Senario Dua: Rangkaian Sosial

Rangkaian sosial boleh menggunakan kedai data hubungan yang sama, tetapi ia memperluaskan ciri yang ditetapkan dengan pilihan seperti pautan hubungan, kemas kini status, pemesejan dan "suka". Kemudahan ini boleh dilaksanakan dan dijatuhkan sebagai tindak balas kepada permintaan pengguna - mustahil untuk meramalkan bagaimana mereka akan berkembang. Di samping itu:

Kebanyakan kemas kini data mempunyai satu titik asal: pengguna. Tidak mungkin kita perlu mengemas kini dua atau lebih rekod pada satu-satu masa, jadi fungsi seperti transaksi tidak diperlukan.
• Walaupun apa yang mungkin difikirkan oleh sesetengah pengguna, kemas kini status yang gagal tidak mungkin menyebabkan kemerosotan global atau kerugian kewangan. Antara muka dan prestasi aplikasi mengambil keutamaan yang lebih tinggi daripada integriti data yang mantap.

NoSQL nampaknya sesuai. Pangkalan data membolehkan kami dengan cepat melaksanakan ciri -ciri menyimpan pelbagai jenis data. Sebagai contoh, semua kemas kini status bertarikh pengguna boleh diletakkan dalam satu dokumen dalam koleksi status:

<span>{
</span>  <span>name: [
</span>    <span>"Billy", "Bob", "Jones"
</span>  <span>],
</span>  <span>company: "Fake Goods Corp",
</span>  <span>jobtitle: "Vice President of Data Management",
</span>  <span>telephone: {
</span>    <span>home: "0123456789",
</span>    <span>mobile: "9876543210",
</span>    <span>work: "2244668800"
</span>  <span>},
</span>  <span>email: {
</span>    <span>personal: "bob@myhomeemail.net",
</span>    <span>work: "bob@myworkemail.com"
</span>  <span>},
</span>  <span>address: {
</span>    <span>home: {
</span>      <span>line1: "10 Non-Existent Street",
</span>      <span>city: "Nowhere",
</span>      <span>country: "Australia"
</span>    <span>}
</span>  <span>},
</span>  <span>birthdate: <span>ISODate</span>("1980-01-01T00:00:00.000Z"),
</span>  <span>twitter: '@bobsfakeaccount',
</span>  <span>note: "Don't trust this guy",
</span>  <span>weight: "200lb",
</span>  <span>photo: "52e86ad749e0b817d25c8892.jpg"
</span><span>}</span>

Walaupun dokumen ini boleh menjadi panjang, kita boleh mengambil subset array, seperti kemas kini yang paling terkini. Sejarah status keseluruhan untuk setiap pengguna juga boleh dicari dengan cepat. Sekarang anggap kami ingin memperkenalkan pilihan emotikon ketika menyiarkan kemas kini. Ini akan menjadi masalah menambah rujukan grafik kepada penyertaan baru dalam array kemas kini. Tidak seperti kedai SQL, tidak perlu menetapkan emotikon mesej sebelumnya kepada NULL - logik program kami boleh menunjukkan imej lalai atau tiada jika emotikon tidak ditetapkan.

Senario Tiga: Sistem Pengurusan Gudang

Pertimbangkan sistem yang memantau barangan gudang. Kita perlu merakam:

• Produk yang tiba di gudang dan diperuntukkan ke lokasi/teluk tertentu
• Pergerakan barang di dalam gudang, mis. menyusun semula stok supaya produk yang sama berada di lokasi bersebelahan
• pesanan dan penyingkiran produk seterusnya dari gudang untuk penghantaran.

Keperluan data kami:

1. Maklumat produk generik seperti kuantiti kotak, dimensi dan warna boleh disimpan, tetapi data diskret kita dapat mengenal pasti dan memohon apa -apa. Kami tidak mungkin bimbang dengan spesifik, seperti kelajuan pemproses komputer riba atau anggaran hayat bateri telefon pintar.
2. Adalah penting untuk meminimumkan kesilapan. Kami tidak boleh mempunyai produk yang hilang atau dipindahkan ke lokasi di mana produk yang berbeza sudah disimpan.
3. Dalam bentuk yang paling mudah, kami merakam pemindahan item dari satu kawasan fizikal ke tempat lain - atau mengeluarkan dari lokasi A dan meletakkan di lokasi B. Itu dua kemas kini untuk tindakan yang sama.

Kami memerlukan kedai yang mantap dengan integriti data yang dikuatkuasakan dan sokongan transaksi. Hanya pangkalan data SQL yang akan (pada masa ini) memenuhi keperluan tersebut.

dedahkan diri anda!

Saya harap senario ini membantu, tetapi setiap projek berbeza dan, pada akhirnya, anda perlu membuat keputusan anda sendiri. (walaupun, kami pemaju mahir untuk membenarkan pilihan teknologi kami, tanpa mengira betapa baiknya mereka!) Nasihat terbaik: mendedahkan diri anda sebanyak mungkin teknologi. Pengetahuan itu akan membolehkan anda membuat penghakiman yang beralasan dan emosi yang tidak adil mengenai SQL atau NoSQL. Semoga berjaya.

Soalan Lazim (Soalan Lazim) Mengenai SQL vs NOSQL

Apakah perbezaan utama antara pangkalan data SQL dan NoSQL? Pangkalan data SQL adalah hubungan, bermakna mereka menganjurkan data dalam jadual dan baris. Mereka menggunakan bahasa pertanyaan berstruktur (SQL) untuk menentukan dan memanipulasi data. Sebaliknya, pangkalan data NoSQL tidak berkaitan dan boleh menyimpan data dalam beberapa cara: pasangan berasaskan dokumen, berasaskan lajur, berasaskan graf atau kunci. Mereka amat berguna untuk bekerja dengan set data yang diedarkan. Yang paling penting. Mereka juga bermanfaat apabila anda perlu melakukan pertanyaan yang kompleks. Pangkalan data SQL adalah mematuhi asid memastikan urus niaga yang boleh dipercayai. tidak jelas atau berubah dari masa ke masa. Mereka menyediakan fleksibiliti, skalabiliti, dan kelajuan, menjadikannya pilihan yang baik untuk aplikasi masa nyata dan data besar.

Bolehkah SQL dan NoSQL wujud bersama dalam projek yang sama? boleh wujud bersama dalam projek yang sama. Ini dikenali sebagai seni bina kegigihan polyglot. Pilihan pangkalan data bergantung kepada keperluan khusus setiap bahagian aplikasi anda.

Apakah pangkalan data SQL dan NoSQL yang popular? Pangkalan data NOSQL yang popular termasuk MongoDB, Cassandra, dan Redis. jadual dan hubungan. Dalam pangkalan data NoSQL, pemodelan data boleh dilakukan dengan pelbagai cara bergantung kepada jenis pangkalan data NoSQL: dokumen, nilai kunci, kolumnar, atau graf. > Pangkalan data SQL biasanya skala secara menegak dengan menambahkan perkakasan yang lebih kuat, sementara skala pangkalan data NoSQL mendatar dengan menambahkan lebih banyak pelayan untuk mengendalikan lebih banyak trafik.

Apakah Teorem Cap dan bagaimana ia terpakai kepada SQL dan NOSQL? , dan toleransi partition. Pangkalan data SQL mengutamakan konsistensi dan ketersediaan, manakala pangkalan data NoSQL mengutamakan ketersediaan dan toleransi partition. untuk urus niaga. Pangkalan data NoSQL, sebaliknya, biasanya tidak menyediakan semua sifat asid. Sebaliknya, mereka memberi tumpuan kepada model asas (pada dasarnya tersedia, lembut, akhirnya konsisten). Urus niaga seperti sistem perakaunan atau sistem yang memerlukan pertanyaan yang kompleks. Pangkalan data NoSQL sangat sesuai untuk aplikasi yang perlu mengendalikan sejumlah besar data dan skala secara mendatar seperti sistem pengurusan kandungan, analisis masa nyata, dan aplikasi IoT.

Atas ialah kandungan terperinci SQL vs NOSQL: Cara Memilih. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!