Mengapa tidak ada cinta untuk SQL? [Tutup]

Akhir-akhir ini saya sering mendengar bahwa SQL adalah bahasa yang buruk, dan tampaknya setiap kerangka kerja di bawah matahari sudah dikemas sebelumnya dengan lapisan abstraksi database.

Dalam pengalaman saya, SQL seringkali merupakan cara yang jauh lebih mudah, lebih fleksibel, dan lebih ramah programmer untuk mengelola input dan output data. Setiap lapisan abstraksi yang saya gunakan tampaknya merupakan pendekatan yang sangat terbatas tanpa manfaat nyata.

Apa yang membuat SQL begitu buruk, dan mengapa lapisan abstraksi database berharga?

Ini sebagian subjektif. Jadi ini pendapat saya:

SQL memiliki gaya bahasa pseudo-natural . Para penemu percaya bahwa mereka dapat membuat bahasa seperti bahasa Inggris dan kueri basis data akan sangat sederhana. Kesalahan besar. SQL sangat sulit dipahami kecuali dalam kasus-kasus sepele.

SQL bersifat deklaratif. Anda tidak dapat memberi tahu database bagaimana seharusnya melakukan sesuatu, hanya apa yang Anda inginkan sebagai hasil. Ini akan menjadi sempurna dan sangat kuat - jika Anda tidak perlu peduli dengan kinerja. Jadi Anda akhirnya menulis SQL - membaca rencana eksekusi - mengubah kalimat SQL mencoba memengaruhi rencana eksekusi, dan Anda bertanya-tanya mengapa Anda tidak dapat menulis rencana eksekusi sendiri .

Masalah lain dari bahasa deklaratif adalah bahwa beberapa masalah lebih mudah diselesaikan dengan cara imperatif. Jadi, Anda menulisnya dalam bahasa lain (Anda memerlukan SQL standar dan mungkin lapisan akses data) atau dengan menggunakan ekstensi bahasa khusus vendor, misalnya dengan menulis prosedur tersimpan dan sejenisnya. Dengan melakukan itu Anda mungkin akan menemukan bahwa Anda menggunakan salah satu bahasa terburuk yang pernah Anda lihat - karena itu tidak pernah dirancang untuk digunakan sebagai bahasa imperatif.

SQL sudah sangat tua . SQL telah distandarisasi, tetapi terlambat, banyak vendor telah mengembangkan ekstensi bahasa mereka. Jadi SQL berakhir dalam lusinan dialek. Itulah mengapa aplikasi tidak portabel dan salah satu alasan untuk memiliki lapisan abstraksi DB.

Tapi memang benar - tidak ada alternatif yang layak. Jadi kita semua akan menggunakan SQL untuk beberapa tahun mendatang.

Terlepas dari semua yang dikatakan, sebuah teknologi tidak harus buruk untuk membuat lapisan abstraksi berharga .

Jika Anda membuat skrip atau aplikasi yang sangat sederhana, Anda dapat mencampur panggilan SQL dalam kode Anda di mana pun Anda suka. Namun, jika Anda melakukan sistem yang kompleks, mengisolasi panggilan database dalam modul terpisah adalah praktik yang baik dan karenanya mengisolasi kode SQL Anda. Ini meningkatkan pembacaan, pemeliharaan, dan kemampuan pengujian kode Anda. Ini memungkinkan Anda untuk dengan cepat menyesuaikan sistem Anda dengan perubahan dalam model database tanpa memecah semua hal tingkat tinggi, dll.

SQL sangat bagus. Lapisan abstraksi di atasnya membuatnya semakin hebat!

Satu poin dari lapisan abstraksi adalah kenyataan bahwa implementasi SQL cenderung kurang lebih tidak kompatibel satu sama lain karena standarnya sedikit ambigu, dan juga karena sebagian besar vendor telah menambahkan tambahan mereka sendiri (tidak standar) di sana. Artinya, SQL yang ditulis untuk MySQL DB mungkin tidak bekerja sama dengan, katakanlah, Oracle DB - bahkan jika itu "seharusnya".

Saya setuju, bahwa SQL jauh lebih baik daripada kebanyakan lapisan abstraksi di luar sana. Ini bukan kesalahan SQL yang digunakan untuk hal-hal yang tidak dirancang untuknya.

SQL diejek dari beberapa sumber:

• Pemrogram yang merasa tidak nyaman dengan apa pun kecuali bahasa imperatif.
• Konsultan yang harus berurusan dengan banyak produk berbasis SQL yang tidak kompatibel setiap hari
• Vendor database nonrelasional mencoba mematahkan cengkeraman vendor database relasional di pasar
• Pakar database relasional seperti Chris Date yang menganggap implementasi SQL saat ini tidak memadai

Jika Anda tetap menggunakan satu produk DBMS, maka saya pasti setuju bahwa SQL DB lebih fleksibel dan berkualitas lebih tinggi daripada pesaing mereka, setidaknya sampai Anda mencapai penghalang skalabilitas intrinsik dalam model. Tetapi apakah Anda benar-benar mencoba untuk menulis Twitter berikutnya, atau apakah Anda hanya mencoba menjaga beberapa data akuntansi tetap teratur dan konsisten?

Kritik SQL sering menjadi standin untuk kritik RDBMSes. Apa yang tampaknya tidak dipahami oleh para kritikus RDBMS adalah bahwa mereka menyelesaikan kelas besar masalah komputasi dengan cukup baik, dan bahwa mereka ada di sini untuk membuat hidup kita lebih mudah, bukan lebih sulit.

Jika mereka serius tentang mengkritik SQL itu sendiri, mereka akan mendukung upaya seperti Tutorial D dan Dataphor.

Tidak terlalu buruk. Kecenderungan yang tidak menguntungkan dalam industri ini untuk membuang teknologi yang dapat diandalkan sebelumnya ketika sebuah "paradigma" baru muncul. Pada akhirnya, kerangka kerja ini sangat mungkin menggunakan SQL untuk berkomunikasi dengan database jadi bagaimana bisa itu buruk? Meskipun demikian, memiliki lapisan abstraksi "standar" berarti pengembang dapat fokus pada kode aplikasi dan bukan kode SQL. Tanpa lapisan standar seperti itu Anda mungkin akan menulis yang ringan setiap kali Anda mengembangkan sistem, yang hanya membuang-buang tenaga.

SQL dirancang untuk manajemen dan query data berbasis SET. Ini sering digunakan untuk melakukan lebih banyak dan kasus tepi kadang-kadang menyebabkan frustrasi.

PENGGUNAAN SQL yang sebenarnya dapat sangat dipengaruhi oleh desain database dasar bahwa SQL mungkin bukan masalahnya, tetapi desainnya mungkin - dan ketika Anda memasukkan kode warisan yang terkait dengan desain yang buruk, perubahan lebih tidak aktif dan mahal untuk diterapkan ( tidak ada yang suka kembali dan "memperbaiki" hal-hal yang "berfungsi" dan memenuhi tujuan)

Tukang kayu dapat menumbuk paku dengan palu, kayu gergaji dengan gergaji dan papan halus dengan bidang. MUNGKIN untuk "melihat" menggunakan palu dan pesawat, tetapi itu membuat frustrasi.

Saya tidak akan mengatakan itu buruk. Ini tidak cocok untuk beberapa tugas. Misalnya: Anda tidak dapat menulis kode prosedural yang baik dengan SQL. Saya pernah dipaksa untuk bekerja dengan manipulasi set dengan SQL. Aku butuh waktu sepanjang akhir pekan untuk memikirkannya.

SQL dirancang untuk aljabar relasional - di situlah SQL harus digunakan.

Akhir-akhir ini saya sering mendengar bahwa SQL adalah bahasa yang buruk, dan tampaknya setiap kerangka kerja di bawah matahari sudah dikemas sebelumnya dengan lapisan abstraksi database.

Perhatikan bahwa lapisan ini hanya mengubah barang mereka sendiri menjadi SQL. Untuk sebagian besar vendor database SQLadalah satu-satunya cara untuk berkomunikasi dengan mesin.

Dalam pengalaman saya, SQL seringkali merupakan cara yang jauh lebih mudah, lebih fleksibel, dan lebih ramah programmer untuk mengelola input dan output data. Setiap lapisan abstraksi yang saya gunakan tampaknya merupakan pendekatan yang sangat terbatas tanpa manfaat nyata.

… Alasan yang baru saja saya jelaskan di atas.

Lapisan database tidak menambahkan apapun, mereka hanya membatasi Anda. Mereka membuat kueri yang disengketakan menjadi lebih sederhana tetapi tidak pernah lebih efisien.

Menurut definisi, tidak ada apa pun di lapisan database yang tidak ada di dalamnya SQL.

Apa yang membuatnya SQLbegitu buruk, dan mengapa lapisan abstraksi database berharga?

SQL adalah bahasa yang bagus, namun, dibutuhkan beberapa putaran otak untuk mengatasinya.

Secara teori, SQLbersifat deklaratif, yaitu Anda menyatakan apa yang ingin Anda dapatkan dan mesin menyediakannya dengan cara tercepat.

Dalam praktiknya, ada banyak cara untuk merumuskan kueri yang benar (yaitu kueri yang mengembalikan hasil yang benar).

Pengoptimal dapat membangun kastil Lego dari beberapa algoritme yang telah ditentukan sebelumnya (ya, ada beberapa), tetapi mereka tidak dapat membuat algoritme baru. Masih dibutuhkan SQLpengembang untuk membantu mereka.

Namun, beberapa orang mengharapkan pengoptimal menghasilkan "rencana terbaik", bukan "rencana terbaik yang tersedia untuk kueri ini dengan penerapan SQLmesin yang diberikan".

Dan seperti yang kita ketahui bersama, ketika program komputer tidak memenuhi harapan orang, programlah yang disalahkan, bukan harapannya.

Namun, dalam banyak kasus, merumuskan ulang kueri dapat menghasilkan rencana terbaik. Ada tugas ketika tidak mungkin, namun, dengan peningkatan yang baru dan terus berkembang untuk SQLkasus ini semakin sedikit jumlahnya.

Alangkah baiknya, jika vendor menyediakan beberapa akses tingkat rendah ke fungsi seperti "get the index range", "get a row by the rowid" dll., Seperti Ccompiler memungkinkan Anda untuk menyematkan assembly langsung ke dalam bahasa.

Saya baru-baru ini menulis artikel tentang ini di blog saya:

• Berpikir ganda dalam SQL

Saya seorang pendukung ORM yang besar dan saya masih percaya bahwa SQL sangat berguna, meskipun tentu saja mungkin untuk melakukan hal-hal buruk dengannya (seperti yang lainnya). .

Saya melihat SQL sebagai bahasa super efisien yang tidak memiliki penggunaan ulang kode atau pemeliharaan / pemfaktoran ulang sebagai prioritas.

Jadi pemrosesan secepat kilat adalah prioritas. Dan itu bisa diterima. Anda hanya perlu menyadari pengorbanannya, yang bagi saya cukup besar.

Dari sudut pandang estetika, sebagai bahasa saya merasa kekurangan beberapa hal karena tidak memiliki konsep OO dan sebagainya - rasanya kode prosedural sekolah yang sangat kuno bagi saya. Tapi itu jauh dan cara tercepat untuk melakukan hal-hal tertentu, dan itu ceruk yang kuat!

Saya akan mengatakan bahwa lapisan abstraksi database yang disertakan dengan kerangka kerja adalah hal yang baik karena memecahkan dua masalah yang sangat penting:

1. Itu membuat kode berbeda. Dengan meletakkan SQL ke lapisan lain, yang umumnya sangat tipis dan seharusnya hanya melakukan dasar-dasar kueri dan penyerahan hasil (dengan cara standar), Anda menjaga aplikasi Anda bebas dari SQL yang berantakan. Itu alasan yang sama pengembang web (harus) meletakkan CSS dan Javascript di file terpisah. Jika Anda bisa menghindarinya, jangan mencampur bahasa Anda .

2. Banyak programmer benar-benar buruk dalam menggunakan SQL. Untuk alasan apa pun, sejumlah besar pengembang (terutama pengembang web) tampaknya sangat, sangat buruk dalam menggunakan SQL, atau RDBMS secara umum. Mereka memperlakukan database (dan SQL dengan ekstensi) sebagai perantara kecil yang kotor yang harus mereka lalui untuk mendapatkan data. Hal ini menyebabkan database yang dipikirkan dengan sangat buruk tanpa indeks, tabel ditumpuk di atas tabel dengan cara yang meragukan, dan kueri yang ditulis dengan sangat buruk. Atau lebih buruk, mereka mencoba untuk menjadi terlalu umum (Sistem Pakar, siapa?) Dan tidak dapat menghubungkan data dengan cara yang berarti.

Sayangnya, terkadang cara seseorang mencoba memecahkan masalah dan alat yang mereka gunakan, apakah karena ketidaktahuan, keras kepala, atau sifat lainnya, bertentangan langsung satu sama lain, dan semoga berhasil meyakinkan mereka tentang hal ini. Dengan demikian, selain hanya menjadi praktik yang baik, saya menganggap lapisan abstraksi database sebagai semacam jaring pengaman, karena tidak hanya membuat SQL tidak terlihat oleh pengembang yang buruk, tetapi juga membuat kode mereka jauh lebih mudah untuk direfraktor, karena semua kueri ada di satu tempat.

SQL sangat baik untuk jenis tugas tertentu, terutama memanipulasi dan mengambil set data.

Namun, SQL kehilangan (atau hanya menerapkan sebagian) beberapa alat penting untuk mengelola perubahan dan kompleksitas:

• Enkapsulasi : Mekanisme enkapsulasi SQL kasar. Saat Anda menulis kode SQL, Anda harus tahu segalanya tentang implementasi data Anda. Ini membatasi jumlah abstraksi yang dapat Anda capai.

• Polimorfisme : jika Anda ingin melakukan operasi yang sama pada tabel yang berbeda, Anda harus menulis kode dua kali. (Seseorang dapat mengurangi ini dengan penggunaan pandangan yang imajinatif.)

• Kontrol visibilitas : tidak ada mekanisme SQL standar untuk menyembunyikan potongan kode dari satu sama lain atau mengelompokkannya ke dalam unit logis, sehingga setiap tabel, prosedur, dll. Dapat diakses dari satu sama lain, bahkan ketika itu tidak diinginkan.

• Modularitas dan Pembuatan Versi

Terakhir, pengkodean operasi CRUD secara manual dalam SQL (dan menulis kode untuk menghubungkannya ke aplikasi lainnya) berulang dan rawan kesalahan.

Lapisan abstraksi modern menyediakan semua fitur tersebut, dan memungkinkan kita menggunakan SQL di tempat yang paling efektif sambil menyembunyikan detail implementasi yang berulang dan mengganggu. Ini menyediakan alat untuk membantu mengatasi ketidakcocokan impedansi relasional objek yang memperumit akses data dalam pengembangan perangkat lunak berorientasi objek.

SQL didasarkan pada Teori Himpunan, sementara sebagian besar bahasa tingkat tinggi berorientasi objek saat ini. Pemrogram objek biasanya suka berpikir dalam objek, dan harus melakukan perubahan mental untuk menggunakan alat berbasis Set untuk menyimpan objek mereka. Umumnya, jauh lebih alami (bagi programmer OO) untuk hanya memotong kode dalam bahasa pilihan mereka dan melakukan sesuatu seperti object.save atau object.delete dalam kode aplikasi daripada harus menulis query sql dan memanggil database untuk mencapainya hasil yang sama.

Tentu saja, terkadang untuk hal-hal yang kompleks, SQL lebih mudah digunakan dan lebih efisien, jadi sebaiknya Anda menguasai kedua jenis teknologi tersebut.

IMO, masalah yang saya lihat orang-orang dengan SQL tidak ada hubungannya dengan desain relasional maupun bahasa SQL itu sendiri. Ini berkaitan dengan disiplin pemodelan lapisan data yang dalam banyak hal secara fundamental berbeda dari pemodelan lapisan atau antarmuka bisnis. Kesalahan dalam pemodelan pada lapisan presentasi umumnya jauh lebih mudah untuk diperbaiki daripada pada lapisan data di mana Anda memiliki banyak aplikasi yang menggunakan database. Masalah ini sama dengan yang dihadapi dalam pemodelan lapisan layanan dalam desain SOA di mana Anda harus memperhitungkan konsumen layanan Anda saat ini dan kontrak input dan output.

SQL dirancang untuk berinteraksi dengan model database relasional. Ada model data lain yang telah ada untuk beberapa waktu, tetapi disiplin tentang merancang lapisan data dengan benar ada terlepas dari model teoritis yang digunakan dan dengan demikian, kesulitan yang biasanya dialami pengembang dengan SQL biasanya terkait dengan upaya untuk memaksakan non-relasional. model data ke produk database relasional.

Untuk satu hal, mereka membuatnya mudah untuk menggunakan kueri berparameter, melindungi Anda dari serangan injeksi SQL. Menggunakan SQL mentah, dari perspektif ini, lebih berisiko, yaitu lebih mudah untuk salah dari perspektif keamanan. Mereka juga sering menyajikan perspektif berorientasi objek pada database Anda, sehingga Anda tidak perlu melakukan terjemahan ini.

Banyak dengar akhir-akhir ini? Saya harap Anda tidak bingung dengan gerakan NoSql ini. Sejauh yang saya ketahui, sebagian besar adalah sekelompok orang yang menggunakan NoSql untuk aplikasi web skalabilitas tinggi dan tampaknya lupa bahwa SQL adalah alat yang efektif dalam skenario non "aplikasi web skalabilitas tinggi".

Bisnis lapisan abstraksi hanya tentang memilah-milah perbedaan antara kode Berorientasi Objek dan kode berbasis Tabel-Set seperti SQL suka bicara. Biasanya ini menghasilkan banyak penulisan pelat boiler dan kode transisi yang membosankan di antara keduanya. ORM mengotomatiskan ini dan dengan demikian menghemat waktu bagi orang-orang yang keberatan bisnis.

Untuk pemrogram SQL berpengalaman, sisi buruknya adalah

• Verbositas
• Seperti yang banyak dikatakan di sini, SQL bersifat deklaratif, yang berarti pengoptimalan tidak langsung . Ini seperti reli dibandingkan dengan balap sirkuit.
• Kerangka kerja yang mencoba menangani semua kemungkinan dialek dan tidak mendukung pintasan salah satunya
• Tidak ada kontrol versi yang mudah.

Bagi yang lain, alasannya adalah itu

• beberapa programmer buruk dalam SQL. Mungkin karena SQL beroperasi dengan himpunan, sedangkan bahasa pemrograman bekerja dalam objek atau paradigma fungsional. Berpikir dalam set (persatuan, produk, perpotongan) adalah masalah kebiasaan yang tidak dimiliki beberapa orang.
• beberapa operasi tidak cukup jelas: yaitu pada awalnya tidak jelas bahwa di mana dan memiliki filter set yang berbeda.
• ada terlalu banyak dialek

Tujuan utama kerangka kerja SQL adalah untuk mengurangi pengetikan Anda. Entah bagaimana mereka melakukannya, tetapi terlalu sering hanya untuk pertanyaan yang sangat sederhana. Jika Anda mencoba melakukan sesuatu yang rumit, Anda harus menggunakan string dan banyak mengetik. Kerangka kerja yang mencoba menangani segala kemungkinan, seperti SQL Alchemy, menjadi terlalu besar, seperti bahasa pemrograman lainnya.

[Pembaruan pada 26.06.10] Baru-baru ini saya bekerja dengan modul Django ORM . Ini adalah satu-satunya kerangka kerja SQL yang layak yang pernah saya lihat. Dan yang satu ini membuat bekerja dengan banyak hal. Agregat kompleks sedikit lebih sulit.

SQL bukanlah bahasa yang buruk, hanya saja SQL terkadang tidak bisa digunakan dengan baik dengan orang lain.

Jika misalnya jika Anda memiliki sistem yang ingin merepresentasikan semua entitas sebagai objek dalam beberapa bahasa OO atau lainnya, maka menggabungkan ini dengan SQL tanpa lapisan abstraksi apa pun dapat menjadi agak rumit. Tidak ada cara mudah untuk memetakan kueri SQL yang kompleks ke dunia OO. Untuk meredakan ketegangan di antara dunia-dunia itu, lapisan abstraksi tambahan dimasukkan (OR-Mapper misalnya).

SQL adalah bahasa yang sangat bagus untuk manipulasi data. Dari perspektif pengembang, yang tidak saya sukai adalah bahwa mengubah database tidak merusak kode Anda pada waktu kompilasi ... Jadi saya menggunakan abstraksi yang menambahkan fitur ini dengan harga kinerja dan mungkin ekspresi bahasa SQL , karena di sebagian besar aplikasi Anda tidak memerlukan semua hal yang dimiliki SQL.

Alasan lain mengapa SQL dibenci, adalah karena database relasional.

The CAP Teorema menjadi populer:

Sasaran apa yang mungkin Anda inginkan dari sistem data bersama?

• Konsistensi Kuat: semua klien melihat tampilan yang sama, bahkan saat ada pembaruan
• Ketersediaan Tinggi: semua klien dapat menemukan beberapa replika data, bahkan jika ada kegagalan
• Toleransi partisi: properti sistem berlaku bahkan ketika sistem dipartisi

Teorema menyatakan bahwa Anda selalu dapat memiliki hanya dua dari tiga properti CAP pada waktu yang sama

Alamat database relasional Konsistensi Kuat dan Partisi-Toleransi.

Jadi, semakin banyak orang menyadari bahwa database relasional bukanlah peluru perak, dan semakin banyak orang mulai menolaknya demi ketersediaan tinggi, karena ketersediaan tinggi membuat penskalaan horizontal lebih mudah. Penskalaan horizontal mendapatkan popularitas karena kita telah mencapai batas hukum Moore , jadi cara terbaik untuk menskalakan adalah menambahkan lebih banyak mesin.

Jika database relasional ditolak, SQL juga ditolak.

SQL memiliki banyak kekurangan, seperti yang ditunjukkan oleh beberapa poster lain di sini. Namun, saya lebih suka menggunakan SQL daripada banyak alat yang ditawarkan orang sebagai alternatif, karena "penyederhanaan" seringkali lebih rumit daripada hal yang seharusnya mereka sederhanakan.

Teori saya adalah bahwa SQL ditemukan oleh sekelompok pemain ski biru menara gading. Seluruh struktur non-prosedural. Kedengarannya bagus: beri tahu saya apa yang Anda inginkan daripada bagaimana Anda ingin melakukannya. Namun dalam praktiknya, seringkali lebih mudah untuk hanya memberikan langkah-langkahnya. Seringkali ini tampak seperti mencoba memberikan instruksi perawatan mobil dengan menjelaskan bagaimana kinerja mobil setelah Anda selesai. Ya, Anda bisa berkata, "Saya ingin mobil sekali lagi menempuh jarak 30 mil per galon, dan berlari dengan suara senandung seperti ini ... hmmmm ... dan, dll." Tapi bukankah akan lebih mudah bagi semua orang untuk ucapkan saja, "Ganti busi"? Dan bahkan ketika Anda menemukan cara untuk mengekspresikan kueri kompleks dalam istilah non-prosedural, mesin database sering kali menghasilkan rencana eksekusi yang sangat tidak efisien untuk mencapainya.

Dan penanganan null membuatku gila! Ya, secara teori pasti kedengarannya bagus ketika seseorang berkata, "Hei, jika nol berarti tidak diketahui, maka menambahkan nilai yang tidak diketahui ke nilai yang diketahui seharusnya memberikan nilai yang tidak diketahui. Bagaimanapun, menurut definisi, kita tidak tahu apa nilai yang tidak diketahui itu . " Secara teoritis, benar sekali. Dalam praktiknya, jika kita memiliki 10.000 pelanggan dan kita tahu persis berapa banyak hutang 9.999 kepada kita, tetapi ada beberapa pertanyaan tentang jumlah yang terhutang oleh yang terakhir, dan manajemen berkata, "Berapa total piutang kita?", Ya, secara matematis benar jawabannya adalah "Saya tidak tahu". Tetapi jawaban praktisnya adalah "kami menghitung $ 4.327.287,42 tetapi satu akun dipertanyakan sehingga angka itu tidak tepat". Saya yakin manajemen lebih suka mendekati jika bukan angka tertentu daripada tatapan kosong.

Semua yang dikatakan, saya masih lebih suka menggunakan SQL daripada beberapa lapisan yang dibangun di atas SQL, yang hanya menciptakan seluruh rangkaian hal-hal lain yang perlu saya pelajari, dan kemudian saya harus tahu bahwa pada akhirnya ini akan diterjemahkan ke SQL, dan terkadang Saya hanya bisa mempercayainya untuk melakukan terjemahan dengan benar dan efisien, tetapi ketika semuanya menjadi rumit saya tidak bisa, jadi sekarang saya harus tahu lapisan tambahan, saya masih harus tahu SQL, dan saya harus tahu bagaimana itu akan menerjemahkan agar saya bisa mengelabui layer untuk mengelabui SQL agar melakukan hal yang benar. Arggh.

• Setiap vendor mengembangkan sintaks SQL untuk menyesuaikan dengan kebutuhan mereka. Jadi, kecuali Anda melakukan hal-hal yang cukup sederhana, kode SQL Anda tidak portabel.

• Sintaks SQL tidak ortogonal; misalnya, pernyataan select, insert, update,dan deletesemuanya memiliki struktur sintaksis yang sama sekali berbeda.

Saya setuju dengan poin Anda, tetapi untuk menjawab pertanyaan Anda, satu hal yang membuat SQL begitu "mengerikan" adalah kurangnya standarisasi T-SQL yang lengkap antara vendor database (Sql Server, Oracle dll.), Yang membuat kode SQL tidak mungkin benar-benar portabel. Lapisan abstraksi basis data memecahkan masalah ini, meskipun dengan biaya kinerja (terkadang yang sangat parah).

Hidup dengan SQL murni benar-benar bisa menjadi neraka pemeliharaan. Bagi saya keuntungan terbesar dari ORM adalah kemampuan untuk refactor kode dengan aman tanpa prosedur "DB refactoring" yang membosankan. Ada kerangka kerja pengujian unit yang bagus dan alat pemfaktoran ulang untuk bahasa OO, tetapi saya belum melihat mitra Resharper untuk SQL, misalnya.

Masih semua DAL memiliki SQL di belakang layar, dan Anda masih perlu mengetahuinya untuk memahami apa yang terjadi pada database Anda, tetapi bekerja sehari-hari dengan lapisan abstraksi yang baik menjadi lebih mudah.

Jika Anda belum pernah menggunakan SQL terlalu banyak, saya pikir masalah utamanya adalah kurangnya alat pengembang yang baik.

Jika Anda memiliki banyak pengalaman dengan SQL, Anda akan, pada satu titik atau lainnya, dibuat frustrasi oleh kurangnya kendali atas rencana eksekusi. Ini adalah masalah inheren dalam cara SQL ditentukan untuk vendor. Saya pikir SQL perlu menjadi bahasa yang lebih kuat untuk benar-benar memanfaatkan teknologi yang mendasarinya (yang sangat kuat).

Cepat, tulis saya SQL untuk membuat paginasi set data yang berfungsi di MySQL, Oracle, MSSQL, PostgreSQL, dan DB2.

Oh, benar, SQL standar tidak menentukan operator apa pun untuk membatasi jumlah hasil yang kembali dan baris mana yang harus dimulai.

Tidak ada cinta untuk SQL karena SQL buruk dalam sintaksis, semantik dan penggunaan saat ini. Saya akan menjelaskan:

• sintaksnya adalah pecahan peluru cobol, semua kritik cobol berlaku di sini (pada tingkat yang lebih rendah, agar adil). Mencoba menjadi bahasa alami seperti tanpa benar-benar mencoba menafsirkan bahasa alami menciptakan sintaks arbirtrary (apakah itu DROP TABLE atau DROP, UPDATE TABLE, UPDATE atau UPDATE IN, DELETE atau DELETE FROM ...) dan monstrositas sintaksis seperti SELECT (berapa banyak halaman yang itu terisi?)
• semantik juga sangat cacat, Date menjelaskannya dengan sangat rinci, tetapi cukup untuk dicatat bahwa tiga logika boolean bernilai tidak benar-benar cocok dengan aljabar relasional di mana sebuah baris hanya dapat menjadi atau tidak menjadi bagian dari tabel
• memiliki bahasa pemrograman sebagai antarmuka utama (dan seringkali hanya) ke database terbukti menjadi pilihan yang sangat buruk dan itu menciptakan kategori baru kelemahan keamanan

Saya setuju dengan sebagian besar posting di sini bahwa perdebatan tentang kegunaan SQL sebagian besar bersifat subjektif, tetapi menurut saya ini lebih subjektif dalam sifat kebutuhan bisnis Anda.

Bahasa deklaratif, seperti yang ditunjukkan Stefan Steinegger, bagus untuk menentukan apa yang Anda inginkan, bukan bagaimana Anda ingin melakukannya. Ini berarti bahwa berbagai implementasi SQL Anda layak dari perspektif tingkat tinggi: yaitu, jika yang Anda inginkan hanyalah mendapatkan beberapa data dan tidak ada yang penting, Anda dapat memuaskan diri sendiri dengan menulis kueri yang relatif sederhana, dan memilih implementasi SQL itu tepat untukmu.

Jika Anda bekerja pada level yang jauh "lebih rendah", dan Anda perlu mengoptimalkan semua itu sendiri, itu jauh dari ideal. Menggunakan lapisan abstraksi lebih lanjut dapat membantu, tetapi jika yang sebenarnya Anda coba lakukan adalah menentukan metode untuk mengoptimalkan kueri dan seterusnya, menambahkan perantara saat mencoba mengoptimalkan akan sedikit berlawanan.

Masalah terbesar yang saya miliki dengan SQL adalah seperti bahasa "standar" lainnya, hanya ada sedikit standar yang sebenarnya. Saya hampir lebih suka belajar bahasa baru antara Sybase dan MySQL sehingga saya tidak bingung dengan kedua konvensi tersebut.

Meskipun SQL benar-benar menyelesaikan pekerjaan itu pasti memiliki masalah ...

• ia mencoba untuk secara bersamaan menjadi abstraksi tingkat tinggi dan tingkat rendah , dan itu ... aneh. Mungkin seharusnya ada dua atau lebih standar di tingkat yang berbeda.
• itu adalah kegagalan besar sebagai standar . Banyak hal yang tidak beres ketika sebuah standar mengaduk dalam segala hal, meminta terlalu banyak implementasi, meminta terlalu sedikit, atau karena alasan tertentu tidak mencapai tujuan sosial sebagian untuk memotivasi vendor dan pelaksana untuk menghasilkan implementasi lengkap yang dapat dioperasikan secara ketat dan sesuai. Anda tentu tidak bisa mengatakan SQL telah melakukan semua itu. Perhatikan beberapa standar lain dan perhatikan bahwa keberhasilan atau kegagalan standar jelas merupakan faktor dari kerja sama yang bermanfaat yang dicapai:
  • RS-232 ( Buruk , tidak cukup ditentukan, bahkan pin mana yang mentransmisikan dan pin mana yang menerima adalah opsional, sungguh. Anda dapat mematuhi tetapi tetap tidak mencapai apa pun. Kesempatan interop yang berhasil: sangat rendah sampai PC IBM membuat standar yang berguna secara de-facto .)
  • IEEE 754-1985 Floating Point ( Buruk , melampaui batas: tidak ada satu pun superkomputer atau stasiun kerja ilmiah atau mikroprosesor RISC yang pernah mengadopsinya, meskipun akhirnya setelah 20 tahun kami dapat menerapkannya dengan baik di HW. Setidaknya dunia akhirnya tumbuh di dalamnya.)
  • C89, C99, PCI, USB, Java ( Baik , baik standar maupun spesifikasi, mereka berhasil memotivasi kepatuhan yang ketat dari hampir semua orang, dan kepatuhan tersebut menghasilkan interoperasi yang sukses.)
• itu gagal untuk dipilih sebagai database paling penting di dunia . Meskipun ini lebih merupakan titik data daripada alasan, fakta bahwa Google Bigtable bukanlah SQL dan bukan relasional adalah semacam anti-pencapaian untuk SQL.

Saya tidak suka SQL, tetapi saya juga tidak ingin menulisnya sebagai bagian dari apa yang saya kembangkan. DAL bukan tentang kecepatan ke pasar - sebenarnya, saya tidak pernah berpikir bahwa akan ada implementasi DAL yang akan lebih cepat daripada kueri langsung dari kode. Tetapi tujuan DAL adalah untuk abstrak . Abstraksi membutuhkan biaya, dan ini dia akan membutuhkan waktu lebih lama untuk diterapkan.

Namun, manfaatnya sangat besar. Menulis pengujian native di sekitar kode, menggunakan kelas ekspresif, set data yang diketik dengan kuat, dll. Kami menggunakan semacam "DAL", yang merupakan implementasi DDD murni menggunakan Generik di C #. Jadi kami memiliki repositori generik, unit implementasi kerja (transaksi berbasis kode), dan pemisahan logis. Kita dapat melakukan hal-hal seperti membuat tiruan kumpulan data kita dengan sedikit usaha dan benar-benar mengembangkannya sebelum implementasi database. Ada biaya di muka untuk membangun kerangka seperti itu, tapi itu sangat bagus logika bisnis kembali menjadi bintang pertunjukan. Kami menggunakan data sebagai sumber daya sekarang, dan menanganinya dalam bahasa yang kami gunakan secara asli dalam kode. Manfaat tambahan dari pendekatan ini adalah pemisahan yang jelas yang diberikannya. Saya tidak lagi melihat kueri database di halaman web, misalnya. Ya, halaman itu membutuhkan data. Ya, database terlibat. Tapi sekarang, dari mana pun saya mengambil data, ada satu (dan hanya satu) tempat untuk masuk ke kode dan menemukannya. Mungkin bukan masalah besar pada proyek yang lebih kecil, tetapi ketika Anda memiliki ratusan halaman di situs atau puluhan jendela di aplikasi desktop, Anda benar-benar dapat menghargainya.

Sebagai pengembang, saya dipekerjakan untuk menerapkan persyaratan bisnis menggunakan keterampilan logis dan analitis saya - dan penerapan kerangka kerja kami memungkinkan saya untuk menjadi lebih produktif sekarang. Sebagai seorang manajer, saya lebih suka developer saya menggunakan keterampilan logis dan analitis mereka untuk memecahkan masalah daripada menulis SQL. Fakta bahwa kita dapat membangun seluruh aplikasi yang menggunakan database tanpa harus memiliki database hingga mendekati akhir siklus pengembangan adalah hal yang indah. Ini tidak dimaksudkan sebagai pukulan terhadap para profesional database. Terkadang implementasi database lebih kompleks daripada solusinya. SQL (dan dalam kasus kami, Views dan Stored Procs, secara khusus) adalah titik abstraksi di mana kode dapat menggunakan data sebagai layanan. Di toko di mana ada pemisahan yang pasti antara data dan tim pengembangan, ini membantu menghilangkan pola duduk dalam menunggu implementasi dan perubahan database. Pengembang dapat fokus pada domain masalah tanpa mengarahkan kursor ke DBA dan DBA dapat fokus pada penerapan yang benar tanpa diperlukan pengembangsekarang .

Banyak posting di sini tampaknya berpendapat bahwa SQL itu buruk karena tidak memiliki fitur "pengoptimalan kode", dan Anda tidak memiliki kendali atas rencana eksekusi.

Apa mesin SQL pandai adalah untuk datang dengan rencana eksekusi untuk instruksi tertulis, diarahkan Data , sebenarnya isinya . Jika Anda peduli untuk melihat di luar sisi pemrograman, Anda akan melihat bahwa ada lebih banyak data daripada byte yang diteruskan di antara tingkatan aplikasi.