Apakah masih ada kebutuhan untuk menulis SQL?

Dengan begitu banyak alat ORM untuk sebagian besar bahasa modern, apakah masih ada use case untuk menulis dan mengeksekusi SQL dalam suatu program, dalam bahasa / lingkungan yang mendukungnya? Jika demikian mengapa?

Untuk kejelasan: Saya tidak bertanya apakah programmer perlu tahu SQL, atau apakah saya harus memiliki alat SQL di desktop saya. Saya bertanya secara spesifik mengapa saya mungkin memilikinya dalam kode (atau konfigurasi, atau apa pun) yang bertentangan dengan ORM.

• Anda lebih nyaman menulis SQL untuk meminta data daripada menulis kode prosedural.
• ORM Anda, meski cantik untuk dilihat, menghasilkan SQL lambat yang mengerikan di beberapa area kritis.
• Anda perlu memanfaatkan fungsionalitas yang diekspos oleh RDBMS Anda yang tidak / tidak dapat disediakan melalui ORM Anda.
• Setiap kali Anda mengetik SELECT * FROM..., Tuhan membunuh anak kucing. Dan Anda membenci anak kucing.
• Anda tidak menggunakan ORM, OOP, atau bahasa modern.

Menulis SQL yang kompleks

ORM sangat bagus untuk hal-hal dasar. Namun untuk situasi yang kompleks Anda harus menulis SQL.

Jadi singkatnya, pasti ada kebutuhan untuk SQL dan akan selalu begitu.

• Tampilan
• Pemicu
• Kendala
• Paket (SSIS, DTS, dll)
• Kapan saja Anda perlu mengontrol alur eksekusi dengan tepat

ORM tidak membantu Anda membangun, menyetel, atau mengotomatisasi basis data. Itu hanya memberi Anda cara alternatif untuk berinteraksi dengan database setelah Anda melakukan semua hal itu.

Tentu:

• Umumnya ORM merangkum banyak, tetapi pada akhirnya Anda harus tahu apa yang terjadi di balik layar. Ini sangat penting untuk kinerja dan skalabilitas. Meskipun di dalam aplikasi saya tidak menulis banyak SQL tapi saya tahu kira-kira bagaimana SQL atau DDL terlihat.
• SQL langsung seringkali baik untuk menulis kueri baca-saja. Jauh lebih mudah untuk merumuskannya dalam bahasa permintaan ORM dan Anda juga dapat membatasi hasil yang ditetapkan (misalnya 'pilih id dari .....').
• ORM seharusnya tidak membuat Anda jauh dari SQL sama sekali. Saya menggunakan SQL banyak untuk permintaan ad-hoc langsung pada DB-client (seperti mysql-client). Ini memberi Anda antarmuka seragam yang sangat bagus dan fungsi pengelompokan.

ORM ada karena ketidakcocokan impedansi antara implementasi DB relasional bersama kami dan fitur bahasa OO kami. Mereka hanya sebuah jembatan, namun kebanyakan orang memperlakukan SQL seperti keju Limburger di lemari es.

Jika Anda dapat mengatakan bahwa Anda akan selalu menggunakan ORM atau lapisan akses data abstrak lainnya alih-alih memperlakukan SQL / prosedur tersimpan / tampilan sebagai antarmuka kelas satu, maka kemungkinan Anda akan lebih baik tanpa menyentuh SQL.

Dalam praktiknya, saya belum pernah melihat proyek murni ORM yang tidak memerlukan setidaknya SQL untuk meminta database untuk validasi akhir.

ORM adalah alat dalam kotak alat pemrogram. Mereka memiliki masalah sendiri. Beberapa contoh adalah:

• Tidak dapat mengontrol sql
• Menderita masalah n +1

Jika Anda tahu apa yang Anda lakukan, Anda dapat secara efektif menggunakan ORM untuk mengganti banyak kode jenis CRUD Anda. Mereka tidak seefektif untuk hal-hal yang kompleks, mereka sulit untuk menyempurnakan kinerja (Anda tahu bahwa kinerja adalah salah satu bagian penting dari desain database, bukan meniru objek) dan mereka benar-benar mengerikan dan berbahaya di tangan seseorang yang tidak bisa mengerti atau menulis SQL sendiri.

Saya juga ingin menunjukkan bahwa pelaporan yang kompleks tidak mudah dilakukan secara efektif dengan ORM. Dan lebih jauh lagi jika Anda tidak belajar SQL sederhana dalam hal-hal sederhana, bagaimana Anda akan sampai pada titik di mana Anda dapat menulis SQL kompleks untuk pelaporan? Saya tidak pernah bekerja dalam aplikasi yang tidak memiliki kebutuhan pelaporan dan seringkali yang cukup rumit.

ORM juga tidak berguna untuk proses BI atau ETL untuk sebagian besar. Mereka juga tidak berguna untuk permintaan admin basis data atau untuk menemukan informasi dalam tabel audit dan membatalkan serangkaian perubahan basis data tertentu. Ada banyak banyak hal yang masih paling efektif dilakukan dengan SQL. Aplikasi yang meminta basis data adalah sebagian kecil dari apa yang dibutuhkan untuk menanyakannya dalam lingkungan Perusahaan.

Saya juga melihat banyak pertanyaan tentang bagaimana melakukan sesuatu menggunakan ORM yang sudah diketahui poster itu di SQL. Sangat menyenangkan untuk mempelajari hal-hal baru, tetapi ketika mereka menyebabkan waktu dan usaha ekstra tanpa keuntungan nyata dari metode asli (dan seringkali kehilangan kinerja yang nyata), mengapa Anda menggunakannya selain mereka "modis" saat ini.

Terkadang klien hanya ingin permintaan cepat dan mudah untuk mengembalikan data untuk laporan, ekspor, datadump, dll dan ingin menunggu seluruh program dikembangkan.

Juga, seorang programmer SQL yang baik selalu dapat menulis lebih cepat, SQL yang lebih efisien daripada ORM yang saya gunakan. Juga, saya telah menemukan banyak orang hanya memiliki poin ORM untuk prosedur tersimpan - benar-benar mengabaikan manfaat dari ORM karena ORM tidak bagus untuk proses yang kompleks.

Juga, ketika menggunakan database seperti Oracle dengan bahasa prosedur yang sangat kaya dan kuat, Anda dapat melakukan banyak hal tanpa pernah membutuhkan "program". PL / SQL on Oracle di tangan kanan sangat cepat dan efisien.

Jika Anda ingin menggunakan database sendiri, ya. Sebagian besar ORM yang saya coba gunakan tidak cukup atau tidak mencakup basis data saya. Selain itu, bagaimana Anda akan memecahkan masalah atau menulis kueri khusus yang tidak tercakup?

Masih diperlukan untuk pemicu penulisan dan prosedur tersimpan. Prosedur yang tersimpan mungkin tidak disukai saat ini, tetapi masih sangat berguna dalam beberapa situasi. SQL mungkin juga diperlukan untuk beberapa sambungan multi-tabel yang sangat berbulu.

Ya, Anda dapat menghindari menulis SQL. Tetapi Anda akhirnya akan menulis HQL (atau Linq, atau DQL ...)!

Serius, saya penggemar berat ORM, dan saya pikir orang mungkin menghindari menggunakan SQL murni sebagian besar waktu. Tetapi kita harus ingat bahwa ORM hanyalah satu abstraksi besar, dan semua abstraksi besar bocor ...

(Tetapi tentang masalah N + 1: ini berkaitan dengan pemuatan malas, dan sebagian besar alat ORM memiliki beberapa cara untuk meminta pemuatan dengan cepat, sehingga menghindari masalah tertentu.)

ORM hanya akan membuat Anda sampai pada titik tertentu. Tetapi ada beberapa kasus ketika Anda harus menjalankan kueri yang sangat rumit, dengan penggabungan yang rumit, subkueri, serikat pekerja, minus, fungsi analitik dll. Saat itulah Anda membutuhkan SQL. Tetapi bagaimana Anda seharusnya menulis pertanyaan yang rumit ketika Anda menyerahkan semua pertanyaan sederhana ke ORM?

Bahkan jika Anda tidak perlu menuliskannya dalam kode Anda, cukup berguna untuk dapat menggunakannya ketika Anda memiliki akses terminal ke server database.

Juga, sebagian besar dari apa yang membuat pemrograman tantangan bekerja dalam batasan bahwa hidup set kita-sering kita sedang bekerja dengan kode lama, atau versi lama dari database dan tidak memiliki kesempatan untuk menginstal perpustakaan ORM terbaru untuk bahasa apapun kita bekerja dengan. Dalam situasi itu Anda akan membutuhkan alat apa pun yang Anda inginkan.

Sisa waktu Anda mungkin tidak perlu SQL untuk hal-hal CRUD Anda, tetapi ada banyak lagi untuk SQL daripada pertanyaan SELECT, INSERT, UPDATE, dan JOIN dasar sederhana. Anda dapat melakukan hal-hal yang sangat pintar dengannya dan meskipun Anda mungkin tidak sering menggunakannya, penting untuk mengetahui apa itu.

Semakin, saya pikir kita akan menemukan diri kita di dunia pasca SQL, namun- sebagian besar layanan Cloud menggunakan penyimpanan tabel non-sql dan untuk jenis pekerjaan CRUD sederhana, kekuatan penuh SQL tidak diperlukan. Tetapi itu tidak berarti tidak akan ada nilai dalam memahaminya.

Juga, tentu saja, seseorang harus cukup tahu untuk menulis sistem ORM yang lebih baik jika yang sekarang tidak terlalu banyak. Ini akan membantu mereka jika mereka tahu SQL ...

Untuk membangun aplikasi web skala besar itu sama sekali tidak perlu dan dapat membuat hal-hal jauh lebih menegangkan dan membuang waktu daripada yang seharusnya. Alasan untuk ini adalah bahwa setiap aplikasi skala besar harus menggunakan lapisan ketekunan memori (dalam RAM) yang harus menjadi bagian caching memori dari DB yang sering digunakan.

Jika Anda harus melakukan sesuatu dengan perangkat seluler, dll. Yang tidak memiliki banyak memori untuk bekerja, di mana aplikasi yang sedang diprogram dijalankan sebagai "klien" atau aplikasi mandiri di perangkat seluler, tablet, dll. hal-hal seperti menggunakan SQL masih umum dan penting karena memori pada perangkat sangat kecil sehingga Anda tidak dapat menyimpan banyak hal dalam memori.

Kompleksitas dan jumlah SQL yang saya tulis tidak cukup untuk membuat mengaitkan kerangka kerja ORM secara wajar.

(Saya menulis SQL mungkin sebulan sekali, jika)

Saya telah menemukan banyak korps besar dengan DBA yang secara aktif takut dev menggunakan alat ORM.

Mereka adalah DBA yang terlibat dalam penyetelan dan kinerja.

Dan ya, alat ORM dapat dikelola untuk melakukan hal-hal seperti ini, tetapi saya telah melihat tempat-tempat di mana mereka hanya akan menerima prosedur tersimpan (Sql Server) dan akan menanyai Anda tentang apa yang Anda lakukan di dalamnya.

Juga, alat ORM dapat disalahgunakan dengan buruk dan menghasilkan Sql yang sama buruknya dengan menulis Sql sendiri.

Satu masalah besar - migrasi DDL & basis data. Terkadang Anda perlu menjahit tangan barang-barang itu untuk memperbarui sesuatu tanpa merusak data yang ada.