Haruskah Anda Menemukan Bahasa Kueri Baru? (Mungkin Tidak)

Unggulan .png

"Apa yang lebih buruk dari silo data? Silo data yang menciptakan bahasa kueri mereka sendiri." -Erik Bernhardsson

Dalam posting blognya yang terkenal dan dibahas secara luas berjudul ' Saya tidak ingin mempelajari bahasa permintaan sampah Anda ,' Erik Bernhardsson mengungkapkan apa yang begitu erat terkait dengan banyak Insinyur dan Analis Data lainnya. Yaitu, bahwa dia "benar-benar [tidak] menyukai perangkat lunak yang menciptakan bahasa kuerinya sendiri" dan bahwa dia "hanya [menginginkan] SQL-nya kembali.

Kata-kata kasar yang cukup singkat namun penuh semangat merangkum pengalaman yang hampir universal bahwa teknologi yang membutuhkan bahasa mereka sendiri sering kali menghasilkan serangkaian kompleksitas baru yang berbeda.

Telah terjadi ledakan berbagai jenis basis data dalam 10 tahun terakhir (Lihat saja jumlah jenis basis data NoSQL di artikel terakhir saya ), dan peningkatan spesialisasi memaksa Insinyur dan Analis Data untuk mempelajari lebih banyak lagi bahasa pemrograman baru.

Masing-masing dari mereka memiliki sintaks dan keanehan spesifiknya sendiri, dan sementara ORM terkadang membantu, mereka sering membuat segalanya menjadi lebih sulit.

Karena itu, Bahasa Kueri baru seringkali diperlukan (seperti dalam kasus database NoSQL). Ini menimbulkan pertanyaan, bagaimana kita bisa tahu apakah bahasa baru benar-benar menambah nilai lebih dari masalah yang diciptakannya? Untuk menjawab ini, kita perlu melihat lebih dalam apa yang menyebabkan semua konflik ini.

Mengapa ada begitu banyak Bahasa Kueri?

Ada banyak Bahasa Kueri di luar sana. Begitu banyak sehingga bahkan daftar terlengkap pun meninggalkan banyak pemain penting. Saya bahkan tidak ingin mencoba mengumpulkan daftar seperti ini karena sepertinya yang baru ditambahkan setiap menit. Jadi mari kita lihat apa penyebabnya?

Singkatnya, ada begitu banyak Bahasa Kueri yang berbeda karena ada begitu banyak hal yang berbeda untuk dikueri. Selain itu, data seringkali harus disimpan dalam berbagai model dengan berbagai jenis skema dan berbagai tingkat pemisahan antara skema fisik dan logis. Misalnya, data yang disimpan dalam database relasional memerlukan teknologi dan sintaks yang berbeda dari data yang disimpan dalam file JSON.

Bahasa query database hierarkis atau jaringan awal akan terlihat sangat berbeda dari bahasa query relasional. Pada hari-hari awal database, seseorang harus secara eksplisit menavigasi jalur antar catatan. Itu juga menjelaskan mengapa dekade terakhir sangat "berbuah" karena tantangan baru yang diciptakan oleh NoSQL. Lihat saja jumlah kategori NoSQL yang berbeda di posting blog terakhir saya .

Bahkan dalam database relasional, vendor yang berbeda ingin menawarkan fitur dan fungsi khusus melalui dialek SQL mereka sendiri (T-SQL, PostgreSQL, dll.).

Semua ini bertambah dengan cepat, dan dalam retrospeksi, tidak dapat dihindari bahwa kami akan berakhir dengan segudang opsi untuk menyimpan dan meminta data. Secara keseluruhan itu adalah hal yang sangat baik karena dengan cara itu, ada peningkatan terus-menerus melalui kompetisi.

Namun, pengembangan melambat karena terlalu banyak bahasa kueri yang berbeda, jadi Object-Relational-Mappers (ORM) diciptakan. Namun, seperti yang akan kita lihat, mereka juga sering memperumit banyak hal.

Mengapa ORM Tidak Selalu Membantu

Pertama-tama mari kita lihat lebih dalam apa itu ORM dan mengapa Anda mungkin ingin menggunakannya.

Object-Relational-Mapping adalah proses yang sering digunakan dalam ilmu komputer untuk mengubah data antara sistem tipe yang tidak kompatibel melalui bahasa pemrograman berorientasi objek . Tujuannya adalah untuk membuat lapisan database abstrak dari 'objek database' yang kemudian dapat ditanyakan menggunakan bahasa pemrograman pilihan Anda.

Singkat cerita, ini memungkinkan Anda untuk berinteraksi dengan database Anda menggunakan bahasa pilihan Anda alih -alih Bahasa Kueri database itu. Ini paling baik dijelaskan melalui contoh cepat menggunakan SQL:

SELECT * FROM users WHERE name = 'Jane Doe';

Pemetaan relasional objek adalah ide untuk menulis kueri seperti di atas dan yang jauh lebih rumit, menggunakan paradigma berorientasi objek dari bahasa pemrograman pilihan Anda. Di situlah ORM masuk. Pustaka ORM yang mengimplementasikan teknik ini dalam bahasa pemrograman yang berbeda. Misalnya, menggunakan JavaScript ORM, kueri di atas sekarang akan terlihat seperti ini:

 var orm = require('generic-orm-library');var user = orm("users").where({ name: 'Jane Doe' });

Tentu saja ada banyak hal baik yang dapat diperoleh dari penggunaan ORM:

  1. No SQL : Jika Anda telah membaca posting blog saya tentang belajar SQL tetapi masih tidak yakin bahwa Anda harus belajar SQL, maka ORM memungkinkan Anda untuk menggunakan bahasa pemrograman pilihan Anda.
  2. No Dialects : ORM mengabstraksi sistem database sehingga beralih dari MySQL ke PostgreSQL, misalnya, jauh lebih mudah.
  3. Fitur Tambahan : Beberapa ORM memiliki fitur-fitur canggih seperti dukungan untuk transaksi, penyatuan koneksi, migrasi, seed, dan aliran yang dapat berguna dalam beberapa kasus.
  4. Kinerja : Jika Anda benar-benar tidak pandai SQL, maka ORM akan berkinerja lebih baik daripada Anda untuk beberapa kueri.

Seperti yang mungkin sudah Anda simpulkan dari judul bagian ini, ada juga banyak kontra:

  1. Kinerja : Jika Anda seorang ahli di SQL, Anda mungkin bisa mendapatkan lebih banyak kueri berkinerja dengan menulisnya sendiri.
  2. Belajar : ORM tidak berfungsi seperti Bahasa Kueri normal, jadi jika itu yang biasa Anda gunakan, ada biaya tambahan yang terlibat dalam mempelajari cara menggunakannya.
  3. Terlalu Banyak : Masalah pembelajaran hanya memburuk ketika Anda mempertimbangkan berapa banyak ORM yang berbeda, dan masing-masing memiliki proses pembelajarannya sendiri.
  4. Konfigurasi : Konfigurasi awal ORM bisa memakan waktu lama dan merepotkan.
  5. Kotak Hitam : Lapisan abstraksi yang disediakan ORM dapat menghalangi untuk mendapatkan masalah sebenarnya dari kueri atau masalah basis data.

Untuk meringkas, dugaan manfaat ORM adalah bahwa mereka mengurangi waktu pengembangan dengan menambahkan lapisan abstraksi, tetapi sering menghasilkan sakit kepala yang lebih besar. Alih-alih menggunakan SQL, Anda sekarang harus menggulir bolak-balik dalam beberapa dokumentasi ORM untuk menentukan cara menulis kueri paling dasar. Debugging juga bisa menjadi masalah karena terkadang ORM menerjemahkan kueri "menjadi beberapa monstrositas yang menggabungkan 17 tabel menggunakan pemindaian tabel lengkap", dan Anda berakhir "dengan kelas data tingkat tinggi yang membengkak daripada tupel atau dict yang mudah dipahami yang berisi data dalam format sederhana bodoh yang sepele untuk diintrospeksi."

Jadi, ORM dapat berguna tetapi tidak selalu membantu dengan masalah yang mendasarinya—sudah ada terlalu banyak bahasa kueri. Jadi apa yang bisa dilakukan? Haruskah kita mengikuti saran Erik dan menerapkan "moratorium 30 tahun untuk menemukan bahasa kueri baru".

Kapan Anda Harus Menemukan Bahasa Kueri Baru?

Sementara seruan Erik untuk moratorium tentu saja lebih merupakan lelucon daripada solusi serius (saya pikir), itu mengungkapkan sentimen bahwa kita perlu berhenti menambahkan begitu banyak bahasa kueri dengan sangat cepat dengan cukup baik.

Sangat dihargai bahwa banyak dari ini diperlukan untuk menangani kelas data baru, cara baru menyimpan data, atau terlalu banyak data baru, tetapi bagaimana kita tahu mana yang diperlukan dan mana yang tidak?

Inilah mengapa saya menyarankan beberapa pertanyaan panduan dan aturan sederhana untuk setiap pengembang baru yang mungkin merasakan dorongan untuk menambahkan ke ekosistem bahasa kueri:

Apakah Bahasa Saya Hanya Dialek Lain?

Yang ini tampaknya terlalu jelas, tetapi bahkan organisasi besar seperti Oracle dan Microsoft tidak dapat mengikuti aturan ini, menghasilkan dialek seperti T-SQL dan PL/SQL.

Pada titik ini, hampir setiap database memiliki caranya sendiri untuk mendefinisikan prosedur tersimpan, fungsi, pemicu, dan perbedaan yang bahkan lebih menonjol daripada kueri dan definisi data.

Misalnya, bahasa skrip untuk Sybase dan SQL Server disebut T-SQL. Sebenarnya, SQL Server adalah database, dan T-SQL adalah bahasanya, tetapi keduanya sering digunakan secara bergantian ketika merujuk pada kode.

Bahasa skrip MySQL sangat berbeda dari T-SQL, seperti yang dapat dilihat dalam dokumentasi di manual referensi. Perbedaan utama pertama yang mungkin Anda temui adalah IF hanya diperbolehkan di blok pemrograman. Yang kedua akan menjadi pembatas, lalu kata go , dan perbedaannya berlipat ganda dari sana.

Jadi tolong jangan buat dialek SQL lain. Itu tidak berarti bahwa kita tidak boleh mengulangi dan meningkatkan SQL, tetapi jangan mencoba melakukan sesuatu yang tidak perlu mewah yang tidak diminta oleh siapa pun karena tidak ada yang mau repot mempelajarinya.

Apakah Bahasa Saya Memecahkan Sesuatu yang Baru?

Aturan ini sangat mirip dengan yang pertama, hanya berlaku lebih luas. Ada banyak database dan jenis data di mana SQL standar tidak dapat menyelesaikan pekerjaan. Graph Database adalah contoh yang baik karena, dalam kasus mereka, baik penyimpanan dan bahasa dirancang khusus untuk melakukan hal-hal yang tidak bisa dilakukan oleh database relasional.

Itu tidak berarti bahwa Anda harus menambahkan ke daftar bahasa Graph Query yang sudah mapan seperti Cypher , yang sudah sangat populer. Itu dibuat oleh Neo4j untuk digunakan dengan basis data grafik mereka sendiri dan akhirnya bersumber terbuka sebagai proyek terpisah yang disebut openCypher , yang memungkinkan basis data apa pun untuk mengimplementasikan bahasa yang sama. Ini sangat visual—menggunakan karakter ASCII untuk membuat bentuk untuk kueri yang bersih dan ekspresif.

MATCH (d:Database)-[:USES]->(Cypher)-[:QUERIES]->(:Model:Graph)

Bahasa kueri grafik lainnya yang banyak digunakan adalah SPARQL , yang terlihat seperti SQL dan dibuat oleh W3C untuk meminta model grafik RDF. Ini tidak biasa seperti dua bahasa lainnya tetapi memiliki fitur unik karena model data subjek-predikat-objek. Itu bahkan dapat digunakan dengan database SQL yang memiliki tabel yang dimodelkan setelah struktur RDF. Beberapa database grafik juga mendukung bahasa mereka sendiri seperti ArangoDB, DGraph, TigerGraph, dll.

Bahasa kueri grafik yang paling umum saat ini adalah GREMLIN , yang merupakan bagian dari kerangka kerja komputasi grafik Apache TinkePop. Sederhana untuk ditulis, mudah dipelajari, dan didukung secara luas oleh banyak basis data grafik dan bahkan basis data non-grafik yang dapat meniru kueri grafik. Di sisi lain, ini bisa bertele-tele untuk kueri yang panjang tetapi umumnya berfungsi dengan baik untuk pekerjaan OLTP dan analisis.

gV().has("lang","gremlin").out("supported_by").values("db_name")

Karena itu, waktunya sudah matang untuk bahasa kueri grafik standar internasional. Vendor industri, termasuk Neo4j dan TigerGraph, telah menyerukan hal ini, dan saya sangat setuju. Karena grafik terus melihat adopsi secara luas, kami pasti telah mencapai titik kritis untuk industri ini, dan pada titik ini, Anda mungkin akan lebih banyak ruginya daripada manfaatnya dengan menambahkan bahasa lain ke dalam campuran.

Apakah Bahasa Saya Mudah Digunakan?

Jika Anda telah sampai sejauh ini dan bahasa Anda memecahkan kasus penggunaan baru yang belum pernah dikerjakan sebelumnya, Anda mungkin benar-benar ada benarnya dengan membuat bahasa kueri Anda sendiri—inilah sebabnya pertanyaan terakhir berfokus pada bagaimana Anda harus melakukannya bahwa.

Tanyakan pada diri sendiri, "Berapa lama waktu yang dibutuhkan orang lain untuk mempelajari bahasa baru saya?". Jika jawaban Anda adalah "beberapa minggu", maka Anda harus mulai mendedikasikan banyak waktu untuk menyederhanakan sintaks Anda sebanyak mungkin.

Ini tidak hanya berarti membuat tutorial dan dokumentasi, yang seharusnya sudah cukup jelas. Sebaliknya, ini berarti Anda harus melakukan upaya serius untuk menyediakan proses dan abstraksi yang memungkinkan pemula memahami bahasa Anda dan menyelesaikan kasus penggunaan utama Anda dalam hitungan jam, jika bukan menit.

Jika Anda merasa tidak bisa melakukannya, bahasa Anda mungkin belum siap.

Kesimpulan

SQL adalah salah satu bahasa pemrograman yang paling banyak digunakan saat ini, tetapi banyak orang lain yang layak mendapatkan pengakuan juga. Bahasa-bahasa ini sering dikaitkan dengan teknologi spesifik yang memecahkan kasus penggunaan yang tidak bisa dilakukan oleh basis data relasional.

Namun, ini telah menyebabkan produksi bahasa kueri yang berlebihan, yang secara signifikan memperlambat waktu pengembangan karena kurva pembelajaran yang curam. ORM diperkenalkan untuk memecahkan masalah itu tetapi akhirnya semakin memperumit masalah.

Itulah sebabnya pengembang yang cerdas harus berhati-hati dalam memperkenalkan bahasa kueri lain ke dalam campuran. Untuk memandu keputusan ini, saya memaparkan beberapa pertanyaan kunci yang harus mereka tanyakan pada diri mereka sendiri untuk melihat baik-baik ekosfer yang ada, kasus penggunaan, dan kesederhanaan.

Meskipun demikian, tidak ada yang lebih baik daripada bekerja di SQL yang baik, terutama ketika Anda memiliki akses ke editor SQL kelas dunia seperti Arctype.

Arctype telah membangun editor SQL kolaboratif yang memungkinkan Anda berbagi database, kueri, dan dasbor dengan siapa pun dengan mudah. Bergabunglah dengan komunitas kami yang sedang berkembang dan coba Arctype hari ini .

July 13, 2021

codeorayo

Ampuh! Ini rahasia mengembangkan aplikasi secara instan, tinggal download dan kembangkan. Gabung sekarang juga! Premium Membership [PRIVATE] https://premium.codeorayo.com

Leave a Reply

Your email address will not be published. Required fields are marked *