Apakah SQL penting jika saya tahu kerangka kerja ORM dengan baik? [Tutup]


51

Saya tidak punya pengalaman serius dalam SQL dan saya bahkan benci menulis SQL daripada LINQ. Saya cukup senang dengan ORM.

Dari sudut pandang pengusaha dan sektor, apakah penting untuk mengetahui SQL? Apakah saya harus menguasainya? Apakah perusahaan yang lebih memilih SQL murni daripada kerangka ORM "dinosaurus" di dunia pemrograman?


14
Saya merasa tua. SQL telah diabstraksi cukup jauh sehingga Anda sekarang dapat dengan serius mengajukan pertanyaan ini.
Tandai

11
@ Mark: Mungkin Anda serius dapat mengajukan pertanyaan, tetapi jawabannya masih sama.
Adam Robinson

30
apakah mengetahui aritmatika masih penting jika saya bisa menggunakan kalkulator?
Steven A. Lowe

4
NHibernate tanpa sepengetahuan SQL Profiler dan bagaimana menggelitik perutnya untuk menggunakan GABUNG, adalah kinerja jihad yang menunggu untuk terjadi pada server basis data Anda
Chris S

2
Apakah Anda harus tahu HTML jika Anda dapat menggunakan Dreamweaver?
Tulains Córdova

Jawaban:


63

Ini sulit untuk dijelaskan kepada banyak programmer, karena jika Anda hanya tahu SQL dasar maka itu benar - benar tidak memberi Anda banyak keuntungan dibandingkan kruk ORM. Konsep SQL yang lebih maju, bagaimanapun, adalah bagian penting dari perbedaan antara aplikasi yang hanya berfungsi vs aplikasi yang berkualitas tinggi (khususnya, cepat dan dapat diandalkan).

Saya berasumsi orang lain mendesain database untuk Anda, karena melakukan itu tanpa mengetahui ada SQL di luar batas. Tetapi bahkan jika Anda hanya berkembang melawan mereka, berikut ini hanya sebagian daftar dari semua hal yang cenderung ORM lakukan dengan buruk atau tidak sama sekali:

  • Kueri rekursif dan / atau hierarki
  • Parameter opsional (terutama menerjemahkannya ke dalam rentang predikat)
  • Jenis data yang ditentukan pengguna
  • Jenis platform khusus (SQL hierarki dan TVPs, array Oracle dan tabel bersarang, dll.)
  • Sisipan / pembaruan / peringatan / penghapusan batch
  • Petunjuk indeks
  • Petunjuk kunci (terutama perbarui kunci dan pembacaan kotor)
  • Menangani kesalahan
  • Gabungan luar - hasilnya membuat peta dengan buruk pada model OOP, banyak ORM memiliki bahasa permintaan mereka sendiri tetapi itu mirip dengan mengetahui SQL itu sendiri;
  • Modularisasi melalui prosedur tersimpan dan UDF, terutama permintaan UDF dan CROSS APPLY inline
  • Penggunaan OUTPUT / RETURNING untuk mementaskan data ke dalam beberapa tabel
  • Kueri paging yang efisien
  • Kueri berdasarkan fungsi windowing (rownum, peringkat, partisi)

Daftar ini terus dan terus - banyak di antaranya adalah hal-hal yang belum pernah dilakukan DBA pemula, dan pengembang pemula belum pernah mendengar - tetapi mereka sangat penting dalam aplikasi skala besar.

ORM benar-benar hebat dalam mempercepat kode SQL yang benar-benar membosankan - yaitu, semua CRUD berulang dan pemetaan dan kode pipa ledeng lainnya, jadi sama sekali tidak ada rasa malu dalam menggunakannya dan tidak mendengarkan siapa pun yang mengatakan mereka jahat. Tapi Anda pasti masih perlu belajar dan ya, bahkan menguasai SQL, dan bersiaplah untuk turun ke perintah / permintaan DB mentah ketika ORM tidak menarik bobotnya.


Saya setuju dengan sebagian besar poin Anda, tetapi mengenai gabungan luar: ya, mereka memetakan buruk ke OOP, tapi saya pikir setara OOP (misalnya GroupJoindalam LINQ) jauh lebih baik.
svick

@vick: Ini memiliki kegunaannya, tapi itu bukan hal yang sama. Coba meniru gabungan luar penuh dengan GroupJoin.
Aaronaught

Ya, itu bukan hal yang sama. Dan saya pikir apa yang paling Anda butuhkan sebenarnya adalah a GroupJoin. Hanya saja orang-orang yang terbiasa dengan SQL segera berpikir tentang join luar dalam kasus-kasus itu dan kemudian bertanya bagaimana menerjemahkannya ke dalam LINQ. Itu bukan pendekatan yang tepat. Anda seharusnya tidak mencoba menerjemahkan SQL Anda ke dalam LINQ, Anda harus menerjemahkan apa yang Anda butuhkan secara langsung.
svick

@vick: Terima kasih atas tipnya. Benci untuk menarik peringkat tetapi setelah absen selama setahun saya masih salah satu kontributor teratas untuk SQL dan Linq pada Stack Overflow, jadi saya cukup yakin saya mengerti perbedaan dalam pendekatan. Gabungan penuh jarang terjadi, tetapi kadang-kadang itu sebenarnya yang Anda butuhkan dan tidak ada analog di Linq. Cukup berantakan dan tidak efisien untuk mendapatkan hasil yang sama , terlepas dari bagaimana itu disusun .
Aaronaught

Sepertinya kita sebenarnya setuju. Dalam kebanyakan kasus, Anda sebenarnya tidak ingin gabung luar. Tetapi ketika Anda melakukannya, sulit untuk menerjemahkannya ke dalam LINQ.
svick

90

Benar! SQL masih merupakan lingua franca dari basis data dan meskipun Anda dapat melakukan banyak hal dengan ORM, Anda harus memahami SQL untuk memahami keputusan yang dibuat ORM dan SQL yang dihasilkannya. Juga, masih ada banyak hal yang harus Anda lakukan dengan sql kustom dan prosedur tersimpan juga. Maaf, tidak ada makan siang gratis.


6
Memang. Anda harus tahu, misalnya, dampak berbagai pernyataan bergabung dan bagaimana pengaruhnya terhadap kinerja.
Chiron

15
+1 Tidak makan siang gratis! Ada apa dengan semua pertanyaan pada dasarnya bertanya apakah ketidaktahuan itu baik-baik saja?
benzado

7
@ Albenzado: Bukannya saya pikir itu dijamin untuk SQL, tetapi Anda harus memilih ketidaktahuan tentang beberapa hal; ada terlalu banyak teknologi (bahkan yang bagus!) untuk benar-benar mengetahui semuanya. Jadi saya pikir tidak apa-apa untuk bertanya "apakah X tidak perlu jika saya mengenal Y dengan sangat baik atau jika saya melakukan Z?"
Craig Walker

2
@Craig Saya setuju ada terlalu banyak di luar sana untuk dipelajari, tetapi seorang programmer benar-benar harus memiliki pengetahuan dasar tentang level di bawah di mana dia bekerja.
benzado

2
Basis data @Craig Walker adalah pengetahuan penting untuk sebagian besar aplikasi bisnis yang tidak menyenangkan untuk dimiliki.
HLGEM

25

Ya, Anda masih perlu tahu SQL. ORM adalah abstraksi yang sangat bocor , dan tidak menyediakan akses ke kekuatan penuh SQL. Untuk aplikasi mainan, Anda mungkin tidak masalah dengan pengetahuan SQL yang terbatas. Untuk aplikasi perusahaan, Anda harus memahami database untuk mendapatkan kinerja yang layak dari ORM. Juga ada banyak sekali tugas yang jauh lebih mudah diselesaikan dengan SQL daripada dengan bahasa aplikasi. Saya telah melihat programmer Java menghabiskan berhari-hari menulis kode untuk melakukan sesuatu yang bisa dikodekan dalam SQL dalam satu jam. Pengetahuan SQL sangat berharga bagi siapa pun yang menulis aplikasi yang menggunakan basis data relasional.


14

Keterampilan SQL adalah harus memiliki keterampilan dalam TI hari ini. LINQ adalah teknologi Microsoft Only. Penggunaan SQL melampaui pengembangan aplikasi web dan klien / server. Anda tidak dapat memodelkan basis data dan melakukan ETL jika Anda tidak baik dengan SQL. Anda mungkin tidak perlu menguasai dialek SQL yang digunakan dalam ORACLE dan SQL Server untuk produk Data Warehous mereka, tetapi Anda harus tahu SQL standar. Dasar-dasar SQL sederhana, ada banyak bahan untuk Anda mulai.


1
Siapa pun yang tahu cara kerja LINQ akan dapat mempelajari SQL dasar dalam sehari. Ini adalah argumen yang mengerikan untuk belajar SQL.
Boris Yankov

6

Jika Anda berinteraksi dengan database SQL, Anda harus memahami SQL yang dihasilkan ORM. Anda harus memahami konsep-konsep yang melekat dalam database SQL, dan Anda harus memahami apa yang tidak bisa dilakukan ORM untuk Anda. ORM membuat hidup lebih mudah (dan ya, saya pikir bekerja tanpa satu memenuhi syarat Anda sebagai dinosaurus dalam banyak kasus), tetapi mereka adalah alat (untuk abstrak hal-hal yang Anda tahu), bukan kruk (untuk mencegah Anda belajar).

Jika Anda menolak untuk belajar SQL, maka Anda tidak memiliki bisnis apa pun yang menyentuh database SQL, baik dengan atau tanpa ORM, dan Anda harus mencari jenis pekerjaan lain.


Sementara saya setuju bahwa mengetahui SQL sangat berguna - pada dasarnya wajib - saya tidak setuju dengan alasan Anda. Dengan alasan itu Anda harus tahu ASM dan arsitektur CPU Anda sebelum menulis program apa pun, karena bahasa tingkat tinggi membuat segalanya lebih mudah tetapi mereka adalah alat (untuk hal-hal yang abstrak), jadi jika Anda menolak untuk mempelajari instruksi dan arsitektur prosesor Anda, Anda tidak perlu menggunakan bisnis komputer. <--- Tidak masuk akal. Alasan sebenarnya Anda membutuhkannya adalah bahwa alat ORM masih dalam masa pertumbuhan; Saya tidak akan terkejut jika 5-10 tahun dari sekarang pengetahuan SQL tidak lagi dibutuhkan
Thomas Bonini

Bahasa tingkat tinggi dibangun sedemikian rupa sehingga mereka mencegah Anda dari harus tahu tentang arsitektur yang mendasarinya, benar. Itu mungkin karena domain tersebut sepadan dengan arsitektur yang mendasarinya. ORM, bagaimanapun, adalah masalah yang berbeda. Saya penggemar berat ORM, tapi saya tidak berpikir satu hari pun akan datang ketika Anda dapat menggunakannya tanpa mengetahui SQL (atau apa pun yang digunakan DB yang mendasarinya). Objek dan model relasional secara fundamental tidak dapat dibandingkan, dan saya pikir akan selalu ada konsep yang tidak diterjemahkan dari satu ke yang lain. Selain itu, saya berbicara tentang
ORM

3
+1: "Jika Anda menolak untuk belajar SQL, maka Anda tidak punya urusan apa pun menyentuh database SQL, baik dengan atau tanpa ORM, dan Anda harus menemukan jenis pekerjaan lain."
Vektor

2
Saya akan memperbaiki ini jutaan kali jika saya bisa. Ada terlalu banyak orang yang tidak memiliki bisnis menyentuh database SQl karena ketidakmampuan umum mereka dan kurangnya pemahaman tentang apa yang mereka lakukan. Mereka menuntut di mana pun mereka pergi membuat pertunjukan pertunjukan dan menulis laporan (bahwa keputusan bisnis sebenarnya dibuat dari) yang memiliki hasil kerja tanpa pernah memperhatikan karena mereka sengaja mengabaikan SQl seolah-olah itu semacam lencana kehormatan untuk memisahkan database. yang sangat penting untuk aplikasi mereka.
HLGEM

1
+1 untuk "alat (untuk mengabstraksikan hal-hal yang Anda ketahui), bukan kruk."
sholsinger

4

Saya akan mengakui bahwa saya adalah penggemar berat ORM dan telah mengajarkan manfaat ORM selama bertahun-tahun dan banyak bicara tentang mengapa ORM mengalahkan SQL.

TAPI...

Saya harus mengakui bahwa SQL benar-benar diperlukan di dunia nyata dan setiap pengembang harus memiliki pemahaman yang baik tentang SQL.

SQL procs lebih cepat daripada ORM di hampir semua kasus. Meskipun Anda dapat optimis output ORM dalam banyak kasus juga membuatnya dekat dengan prok SQL.

Kadang-kadang, Anda memerlukan beberapa tugas berat SQL untuk mendapatkan hasil yang Anda butuhkan, dan permintaan monster ini lebih mudah dan lebih cepat untuk dibuat dalam procs SQL.

Hanya dua bit saya.


4

Akan tiba saatnya Anda harus mengoptimalkan sesuatu yang kompleks yang dibuat ORM. Pada titik itu Anda umumnya memiliki permintaan yang sangat rumit untuk dipecah. Jika Anda tidak pernah mempelajari dasar-dasar, bagaimana Anda bisa mulai belajar SQL dengan hal-hal canggih? Anda tidak akan cukup mengerti untuk memulai. ORM di tangan orang yang mengerti SQL - alat yang bagus. ORM di tangan seseorang yang sama sekali tidak tahu SQL - menunggu bencana terjadi.

Salah satu alasan mengapa SQL sangat penting untuk memahami database adalah bahwa pemrogram aplikasi tidak secara alami berpikir dalam hal kumpulan data. Tetapi satu-satunya cara database beroperasi secara efisien adalah dengan set. Anda perlu belajar cara berpikir dalam set sebelum Anda bahkan mencoba menggunakan ORM.


3

Saya menemukan diri saya secara manual memaksa kueri dalam kerangka kerja ORM lebih sering daripada tidak. Dan sementara sebagian besar memiliki bahasa permintaan mereka sendiri, mereka semua terinspirasi oleh sql, kodenya berubah menjadi sql, dan Anda perlu memahami apa yang salah dengan membaca sql itu ketika (tidak jika, kapan) ada masalah atau berkinerja buruk.
Jadi, bahkan jika Anda tidak menulis sql secara langsung, memahaminya melampaui tingkat dasar (meskipun Anda mungkin tidak perlu mempelajari hal-hal tentang cara menulis prosedur tersimpan, pemicu, dll. Jika yang akan Anda lakukan adalah mengakses basis data) Anda harus tahu bahasa yang cukup untuk memahami kode yang dihasilkan dan menyesuaikannya sesuai kebutuhan.


3

Sebelum saya berbicara tentang pertanyaan, sedikit pengantar dulu; Saya suka ORM. Dan saya benci SQL. Saya suka ORM karena mereka menyembunyikan kekacauan yang tidak ramah pengguna seperti SQL, dan menyediakan cara terintegrasi yang baik dalam menangani database.

Namun saya harus mengakui bahwa SQL memiliki banyak manfaat, dengan yang lebih besar presisi. Saya bisa berargumen tentang kompleksitas query SQL, tanpa pengetahuan rinci tentang skema database yang mendasarinya, hanya dengan memeriksa query. Oleh karena itu, ketika saya menggunakan SQL, saya selalu waspada, dan saya selalu memiliki intuisi tentang ke mana kompleksitas komponen menuju.

Di sisi lain, ketika menggunakan ORM, saya sangat kewalahan dengan kemudahan integrasi database, sehingga saya benar-benar lupa bahkan ada database. Ini telah menipuku beberapa kali. Berkali-kali di masa lalu, saya telah memanggil metode ORM yang tampak tidak bersalah, yang di belakang layar memanggil basis data yang besar dan menakutkan, yang menghancurkan kinerja.

Itu sebabnya bagi saya, kebenaran ada di antara keduanya. Saya suka menggunakan ORM, dan saya akan terus melakukannya, tetapi saya harus lebih berhati-hati dan selalu mempelajari implikasi (pada level SQL) dari setiap panggilan metode ORM. Mengetahui implikasi lapisan abstraksi adalah emas murni dalam bisnis ini, dan membenarkan penggunaan abstraksi. Yang lainnya, seperti menembak diri sendiri.


3
Saya juga berpikir bahwa kadang-kadang (bahkan dengan SQL biasa) orang lupa bahwa hanya karena mengembalikan kumpulan data tidak berarti itu adalah kumpulan data yang benar. Saya pikir ini menjadi lebih mudah untuk dilupakan dengan ORM ketika Anda menganggap itu melakukan hal yang benar karena Anda tidak benar-benar mengerti apa yang dilakukannya.
HLGEM

Saya tidak setuju pada ORM yang kurang kompleks dari SQL. Dengan SQL Anda dapat mengambil data tanpa pemrograman. SQL bukan bahasa pemrograman tetapi bahasa deklaratif, jadi tidak memiliki struktur sementara, untuk atau jika-maka.
Tulains Córdova

1
Bahasa pemrograman deklaratif, masih merupakan bahasa pemrograman. SQL adalah bahasa pemrograman tujuan khusus, dan ya itu deklaratif untuk bagian terbesar. Adapun daging komentar Anda, saya tidak mengerti. SQL sementara bukan bahasa pemrograman tujuan umum, masih merupakan bahasa. Anda masih perlu mengetahui sintaks, batasan dan kekurangannya.
Charalambos Paschalides

2

Jika yang harus Anda lakukan adalah berinteraksi dengan database hanya melalui aplikasi yang Anda buat, Anda mungkin tidak membutuhkannya. Di beberapa perusahaan kecil atau tim pengembang, Anda mungkin harus melakukan beberapa dukungan. Jauh lebih mudah untuk terhubung ke database klien dan menjalankan beberapa pernyataan sql untuk melihat apa yang terjadi dengan data mereka.


Siapa yang perlu berinteraksi dengan database SAJA melalui aplikasi yang sedang ia bangun?
Tulains Córdova

2

Bahkan dengan ORM yang baik dan matang Anda pasti akan mengalami situasi di mana itu mengeluarkan beberapa SQL yang tidak efisien dan itu akan membuat hidup Anda jauh lebih mudah jika Anda dapat memahami apa yang terjadi dalam SQL yang dihasilkan. Yang mengatakan, jika Anda sangat mahir dengan ORM dan tahu cara menggunakan profiler untuk DB pilihan Anda, Anda bisa dengan mudah "berpura-pura sampai Anda membuatnya".


1

Jawaban untuk semua jenis pertanyaan ini ("apakah saya perlu tahu X?") Adalah "pelajari saat pertama kali Anda membutuhkannya, jika Anda membutuhkannya".

Namun penting untuk tidak jatuh ke dalam perangkap melakukan hal-hal yang kurang efisien karena Anda tidak sadar atau tidak mau belajar cara efisien untuk melakukannya.

Dalam kasus khusus ini, misalnya, apa yang Anda lakukan jika Anda menyadari bahwa ada bug dalam program Anda yang menyebabkan PostCountbidang tabel pengguna Anda terkadang tidak akurat.

Anda memperbaiki bug dan sekarang Anda harus memperbarui PostCount untuk semua pengguna. Bagaimana Anda melakukannya?

Jika Anda menulis skrip kecil menggunakan ORM untuk melakukan ini, maka Anda menjadi sangat tidak efisien; query SQL yang sangat sederhana akan dilakukan.

Karena situasi ini cukup umum, saya khawatir Anda jatuh ke dalam perangkap yang dijelaskan di atas!


2
Saya setuju: jika Anda tidak tahu SQL, Anda sering menulis lusinan baris kode untuk melakukan apa yang bisa Anda lakukan dengan satu query SQL.
benzado

2
re "pelajari saat pertama kali Anda membutuhkannya": ro-che.info/ccc/11.html
MatrixFrog

1

Ya, Anda masih membutuhkan SQL.

Jangan langsung berasumsi bahwa sesuatu yang "lama" entah bagaimana tidak layak dipertimbangkan. Teknologi yang disebut "warisan" adalah yang masih ada setelah diuji waktu. Kami tidak menyebut komputer Wang "warisan", mereka gagal, dan hilang.

Jika Anda bertanya kepada saya apakah itu mengganggu saya bahwa bank saya mungkin menggunakan COBOL pada mainframe, atau IBM i? Absolutley tidak. Ini adalah teknologi yang solid, teruji dan benar. Coba tebak, mereka kebanyakan menggunakan DB2 SQL. Saya jauh lebih bahagia memercayai uang saya di sana, daripada dalam perangkat lunak yang dikembangkan dalam bahasa modis bulan ini.

Dinosaurus bertahan di bumi ini lebih lama dari kita manusia. Dan jika Anda membaca Jurasic Park (ya, buku lebih baik daripada film) maka saya bertanya, apakah Anda benar-benar ingin menghadapi sekumpulan velociraptor yang sangat pintar, atau T-Rex yang mantap yang tidak pernah menyerah? Jangan digigit dengan meremehkan "dinosaurus". ;-)


0

Terlepas dari permainan dan penelitian (terutama statistik), yang saya tidak punya pengalaman dengan, tampaknya akses database dan operasi adalah salah satu dari sedikit bidang di mana keputusan yang salah menyebabkan hit kinerja yang sangat besar. Saya sangat percaya pada abstraksi basis data yang lebih kuat dalam kode, dan saya percaya LINQ, yang mengikat operasi basis data dengan bahasa pemrograman, memberi Anda semua alat bahasa (memeriksa jenis, memeriksa sintaksis, semua hal yang Anda sukai tentang bahasa pemrograman Anda) sementara masih memberi Anda banyak kekuatan untuk melakukan apa yang Anda inginkan benar-benar hebat. Sayangnya, itu masih tidak selalu berhasil. Itu berarti, jika lapisan abstraksi salah optimisasinya, dan Anda mungkin menunggu detik bukannya mikrodetik, atau menit bukannya detik untuk hasil Anda. Karena ini adalah waktu yang sangat nyata, Anda harus mengoptimalkannya, atau aplikasi Anda tidak "berfungsi": kinerja menjadi masalah terbesar aplikasi Anda. Itu berarti Anda harus lebih dekat dengan logam, dan mengoptimalkan tangan.

Ketika kita sampai pada titik bahwa memanipulasi dataset besar mengambil contoh 3 ms ketika melakukan dengan tangan, dan 100 ms ketika Anda membiarkan lapisan abstraksi melakukannya untuk Anda, tentu saja, biarkan lapisan abstraksi menanganinya untuk Anda, karena Anda mungkin menjadi 30 kali lebih lambat, tetapi Anda masih (mungkin, untuk sebagian besar aplikasi) cukup cepat. Kenyataan dari situasi ini adalah bahwa ketika Anda melihat solusi yang dioptimalkan secara langsung di mana Anda memiliki waktu respons 200 ms, dan ketika lapisan abstraksi menanganinya untuk Anda, algoritma tersebut mengambil 'hanya' 10 kali kinerja yang berhasil, Anda memiliki Penundaan 2 detik, dan kemudian Anda sangat peduli, mulai dari tidak terlalu cepat, hingga sangat lambat. Melihat bahwa solusi database relasional tidak skala dengan baik, Saya tidak berpikir ini akan diselesaikan dalam dua atau tiga tahun. Ini berarti Anda masih harus pergi ke bare metal untuk beberapa waktu ketika datang ke database yang lebih besar, atau aplikasi Anda akan sangat lambat, tidak dapat bertahan terhadap pesaing.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.