Apa keuntungan menggunakan pembangun query SQL?


17

Apakah ada keuntungan menggunakan pembuat pembangun, daripada menggunakan SQL mentah?

Misalnya

$q->select('*')
  ->from('posts')
  ->innerJoin('terms', 'post_id')
  ->where(...)

vs:

SELECT * FROM posts WHERE ...

Saya melihat bahwa banyak kerangka kerja menggunakan lapisan abstraksi semacam ini, tetapi saya gagal memahami manfaatnya.


Saya pikir orang harus menulis permintaan terhadap tampilan dan bukan terhadap tabel. Saya cenderung berpikir orang yang menggunakan pembuat kueri cenderung tidak menulis tampilan atau meminta DBA untuk membuatnya. Dengan melakukan itu, mereka tidak memanfaatkan semua kekuatan RDBMS.
Tulains Córdova

1
@ user61852: Selain kemungkinan beberapa keamanan dan pemfilteran gratis, pertanyaan apa yang bisa dilakukan terhadap tampilan yang tidak bisa disediakan oleh permintaan terhadap tabel?
Robert Harvey

4
@RobertHarvey Hal yang sama yaitu pemrograman ke antarmuka, bukan kelas konkret. Decoupling dan fleksibilitas. Desain tabel yang mendasari bisa terjadi selama "kontrak", pandangan, tetap "mensimulasikan" kolom yang sama seperti sebelumnya.
Tulains Córdova

@ user61852 Cukup adil.
Robert Harvey

@RobertHarvey Saya mengubahnya menjadi jawaban.
Tulains Córdova

Jawaban:


20

Abstraksi penulisan SQL melalui framework dengan baik, abstrak.

Menulis SQL dengan tangan tidak terlalu buruk dengan sendirinya, tetapi Anda mulai mendapatkan masalah dengan melarikan diri dan membersihkan dan ini berubah menjadi berantakan. Lapisan abstraksi dapat menangani semua ini di belakang layar yang memungkinkan kode Anda bersih dan bebas dari banyak mysql_real_escape_string()panggilan atau sejenisnya.

Selain itu, ini membawa kemungkinan akuntansi untuk dialek SQL yang berbeda. Tidak semua basis data dibuat sama dan mungkin ada variasi kata kunci atau sintaksis fungsi tertentu. Menggunakan lapisan abstraksi membawa kemampuan untuk menghasilkan sintaks yang benar untuk varian Anda secara dinamis.

Sementara lapisan abstraksi dapat menghasilkan hit kinerja, pada umumnya diabaikan dibandingkan dengan kebersihan dan kekokohan kode yang Anda terima sebagai gantinya.


1
Saya tidak berpikir dialek SQL berbeda di RDBMSes. Dan di PHP ada PDO yang melakukan sanitasi untuk Anda
Anna K.

12
Dialek SQL memang berbeda, itulah sebabnya mereka disebut dialek. Adapun PDO, lapisan abstraksi hanya menyembunyikan kekacauan ini dari kami.

@GlennNelson Anna berarti satu dialek, menggunakan backend berbeda (PSQL / MySQL / SQLite ...)
Izkata

2
@AnnaK. Dialek mungkin tidak berubah, tetapi terkadang fitur-fiturnya berbeda. Sebagai contoh, MySQL (dengan mesin MyISAM) tidak mendukung pembatasan Kunci Asing, sementara PostGres melakukannya. Entah dialek harus menangani hal seperti itu sendiri (yang membutuhkan pengetahuan penuh tentang struktur data, seperti yang dilakukan ORANG Django), atau, lebih mungkin: pengguna harus pintar tentang bagaimana mereka menggunakannya, yang dapat membuatnya terlihat seperti perubahan dialek, tergantung pada keadaan.
Izkata

1
+1 untuk membiarkan alat yang dibangun dengan baik melakukan pelarian dan sanitasi untuk Anda. Jika bisa juga melakukan validasi, maka lebih baik lagi.
Dan Ray

11

Pembuat kueri adalah hewan peliharaan yang membenciku, jadi aku menulis Framework (Apeel) sendiri untuk menghindari menggunakannya!

Jika Anda menggunakan PDO (yang saya sarankan pasti Anda lakukan), maka mengesampingkan input ditangani untuk Anda.

Seperti kata orang lain, meskipun mereka membuatnya lebih mudah untuk beralih di antara database, mereka cenderung mendukung fungsionalitas "common common denominator" dan tidak akan mendukung atau memiliki kinerja yang lebih buruk untuk fitur yang lebih canggih.

Saya telah mengembangkan sistem dengan basis data sejak sekitar tahun 1986 dan selama itu saya jarang menemukan perusahaan yang benar-benar mengubah database yang mereka gunakan selain ketika mereka membutuhkan kinerja yang lebih baik. Jika Anda mengubah basis data untuk kinerja yang lebih baik, maka jauh lebih masuk akal untuk menghabiskan waktu Anda secara optimal mengoptimalkan kueri Anda untuk mendapatkan yang terbaik dari basis data baru daripada mengambil hasil dari pembuat kueri demi kesederhanaan.

Waktu yang dihabiskan untuk memahami qwirks pembuat kueri (kemudian belajar kembali ketika Anda beralih ke yang lebih baik) akan jauh lebih produktif menghabiskan waktu belajar bagaimana mengoptimalkan SQL Anda.

Pokoknya itu sebabnya BUKAN menggunakannya, beberapa orang menyukainya.


4

Secara teoretis? Iya. Glenn Nelson menunjukkan bagaimana mereka akan sering membantu Anda. (Jika itu adalah pembuat kueri yang baik).

Dalam praktek? Tidak selalu sesuai dengan teori dan benar-benar dapat menyebabkan masalah. Misalkan Anda menggunakan pembuat kueri terhadap beberapa DBMS populer dan semuanya sangat bagus. Kemudian seorang pelanggan meminta Anda untuk memukul DBMS mereka yang memiliki beberapa kebiasaan yang tidak dapat ditangani oleh pembuat kueri yang Anda pilih. (Saya mengalami masalah ini ketika saya harus bekerja dengan versi Pervasif yang lebih lama.)

TAPI! Apa yang benar-benar harus Anda lakukan adalah memisahkan Layer Akses Data dan memastikan Anda dapat bertukar di yang baru jika diperlukan. Dengan cara itu Anda dapat membuat pembangun permintaan yang keren dengan semua fitur, tetapi jika Anda perlu memasukkan yang baru yang menggunakan pseudo-sql aneh untuk DB yang bersangkutan.


2
Bukankah seharusnya situasi seperti masalah quirk DB diselesaikan sebelumnya? Maksud saya mencari tahu apa DB klien Anda gunakan dan memilih kerangka kerja yang tepat / perpustakaan sesuai adalah sesuatu yang harus ditangani sebelumnya Anda menulis satu baris kode.

3

Saya pikir manfaat praktis, manfaat sehari-hari pembuat kueri - adalah penggunaan kembali kode dan kemampuan untuk mengikuti prinsip KERING.

Dengan pembangun kueri Anda dapat menempatkan bagian SQL yang berulang ke dalam metode. Dan kemudian gunakan metode ini untuk menyusun SQL yang kompleks. Contohnya misalnya klausa JOIN yang dapat digunakan kembali:

function joinTaskWithClient($queryBuilder) {
    $queryBuilder->join('task', 'contract', 'task.contract_id = contract.id')
                 ->join('contract', 'client', 'contract.client_id = client.id');
}

Jadi penggunaannya adalah:

$queryBuilder->select('client.name')
             ->from('client')
             ->where('task.id=:task')->setParameter('task', 42);
joinTaskWithClient($queryBuilder);

Seperti yang Anda perhatikan - dengan pembuat kueri Anda dapat menambahkan bagian-bagian dari SQL dalam urutan apa pun (misalnya, GABUNG bagian setelah WHERE satu) berbeda dengan kasus ketika Anda mengumpulkan string SQL secara manual. Anda juga dapat membaca tentang pola pembangun untuk melihat maksud dan manfaatnya.

Saya setuju untuk keluar dan sanitasi, tetapi ini bisa dicapai tanpa pembuat kueri juga. Mengenai jenis DB / abstraksi dialek - ini adalah keuntungan yang cukup teoretis dan dipertanyakan, jarang digunakan dalam praktik.


Bagi saya, ini juga merupakan manfaat utama. Yang lain adalah bahwa dengan mengabstraksi menjadi metode Anda dapat memberikan metode nama yang lebih bermakna dan bahkan membuat Bahasa Domain Khusus dari ini, membuat maksudnya jauh lebih jelas. Anda juga dapat meneruskan pembuat kueri juga dan membiarkan berbagai komponen menambahkan bit spesifik ke dalamnya. Terakhir, saya menemukan bahwa itu memungkinkan saya untuk merangkum pola di balik metode bernama bermakna .... Saya telah menemukan beberapa pembuat kueri di mana menambahkan kolom secara bodoh menimpa yang sebelumnya, yang jenisnya membuat banyak hal di atas tidak berguna ...
malte

2

saya akan memberikan jawaban berdasarkan file readme dari pembangun SQL kustom saya ( Dialek )

(teks biasa mengikuti, menghapus referensi khusus perpustakaan)

Persyaratan

  1. Mendukung banyak vendor DB (mis. MySQL, PostgreSQL, SQLite, MS SQL / SQL Server, Oracle, DB2, ..)
  2. Mudah diperluas ke DB baru (lebih disukai melalui pengaturan konfigurasi, bebas implementasi,)
  3. Modularitas dan transferability yang bebas implementasi
  4. API Fleksibel dan Intuitif

fitur

  1. template berbasis tata bahasa
  2. dukungan tampilan lunak kustom
  3. db abstraksi, modularitas, dan transferabilitas
  4. template yang disiapkan
  5. data keluar

saya pikir fitur dan persyaratan di atas membuat sketsa alasan orang akan menggunakan pembangun abstrak abstraksi

Sebagian besar fitur di atas didukung oleh sebagian besar pembangun SQL (walaupun saya rasa semua yang terdaftar tidak didukung, sepengetahuan saya)

Contoh kasus penggunaan:

  1. Platform CMS dapat bekerja (tanpa perubahan kode yang mendasarinya) dengan beberapa vendor DB
  2. Kode aplikasi khusus di mana vendor DB cenderung berubah dan / atau skema dB bersifat dinamis (ini berarti banyak kueri tidak dapat dikodekan secara keras tetapi masih perlu diabstraksi cukup sehingga kode kuat untuk diubah)
  3. Prototyping dengan DB lain dari yang digunakan dalam produksi (akan membutuhkan basis kode duplikat setidaknya untuk beberapa kode)
  4. Kode aplikasi tidak digabungkan secara erat dengan penyedia dan / atau implementasi DB tertentu (bahkan dalam vendor DB yang sama, misalnya versi vendor DB yang berbeda), sehingga lebih kuat, fleksibel, dan modular.
  5. Banyak kasus kueri dan pelarian data biasa ditangani oleh kerangka kerja itu sendiri dan biasanya ini adalah optimal dan lebih cepat

Akhirnya, contoh use case yang saya miliki. saya sedang membangun sebuah aplikasi di mana skema DB yang mendasari (wordpress) tidak cocok untuk jenis permintaan data yang perlu dilakukan, ditambah beberapa tabel WP (misalnya posting) harus digunakan (sehingga memiliki tabel yang benar-benar baru) untuk semua data aplikasi bukan opsi).

Dalam hal itu mampu membuat aplikasi seperti MVC di mana model dapat ditanyai oleh kondisi kustom / dinamis membuat permintaan hard-coding hampir menjadi mimpi buruk. Bayangkan harus mendukung permintaan mungkin hingga 2-3 tabel dengan bergabung dan menyaring kondisi untuk melihat tabel apa untuk bergabung dengan apa dan juga mengurus alias yang diperlukan dan sebagainya.

Jelas ini adalah kasus penggunaan abstraksi permintaan dan, bahkan lebih, diperlukan (atau setidaknya sangat diuntungkan dari) memiliki kemampuan untuk mendefinisikan tampilan lunak kustom (konglomerat dari tabel bergabung seolah-olah mereka adalah satu tabel kustom yang cocok untuk model) . Maka itu jauh lebih mudah, lebih bersih, modular dan fleksibel. Dalam aspek lain, aplikasi (kode) juga menggunakan lapisan abstraksi kueri sebagai alat normalisasi (skema db) . Seperti beberapa orang mengatakan, itu adalah bukti masa depan .

Jika, besok, orang-orang memutuskan bahwa mereka memerlukan beberapa opsi atau data tambahan, sangat mudah untuk menambahkannya ke model dalam beberapa baris dan berfungsi dengan baik. Selain itu, jika, besok, orang-orang memutuskan mereka tidak ingin menggunakan wordpress lagi (karena aplikasi ini secara longgar digabungkan ke wordpress sebagai plugin), itu juga relatif mudah untuk diubah ( hanya definisi ) model dalam beberapa baris kode untuk beradaptasi dengan skema baru.

Lihat apa yang saya maksud?


1

Cukup sering, beberapa argumen untuk pertanyaan ini memang beberapa nilai daripada konstanta. Sekarang, banyak dari mereka pada dasarnya berasal dari tulisan formulir pengguna. Dan karenanya ada banyak kemungkinan untuk serangan injeksi SQL. Jadi secara inheren formasi query memang membutuhkan validasi penuh.

Sekarang, ini bukan untuk mengatakan bahwa kami tidak mempercayai pengembang, tetapi pembentukan kueri mungkin mudah, tetapi mengulangi semua pemeriksaan validasi yang mungkin terjadi di mana-mana mungkin hanya menyiratkan bahwa Anda mungkin kehilangan kadang-kadang secara kebetulan atau memodifikasi kueri tetapi tidak memodifikasi kueri tetapi tidak dapat memperbarui pemeriksaan validasi. Beberapa pemula bahkan mungkin tahu semua bahaya kehilangan ini. Oleh karena itu, abstraksi pembuat kueri sangat penting.


0

Saya dulu berpikir pembangun permintaan adalah aplikasi GUI yang memungkinkan Anda untuk memilih tabel dan membuat bergabung secara grafis saat menghasilkan SQL di bawah tenda, tapi sekarang saya mengerti bahwa Anda juga memanggil pembangun permintaan API yang menyediakan cara untuk tidak harus membuat kueri SQL murni , jadi abaikan sendiri perbedaan potensial dalam rasa SQL.

Menggunakan pembangun permintaan seperti itu bagus , tapi saya cenderung berpikir bahwa orang yang sangat bergantung pada mereka cenderung tidak bertanya DBA: "hei, ini adalah permintaan yang saya gunakan banyak, tolong buat pandangan dari itu".

Jangan salah sangka.

Saya pikir Anda harus menulis kueri terhadap tampilan dan bukan tabel. Bukan untuk keamanan atau pemfilteran, yang merupakan alasan bagus, tetapi untuk alasan yang sama Anda harus mengkode terhadap antarmuka dan bukan terhadap kelas konkret: decoupling. Tampilan seperti "kontrak", antarmuka yang sama dengan "kontrak" di OOP. Anda dapat mengubah tabel yang mendasarinya, tetapi selama Anda memaksakan pandangan untuk menunjukkan "kontrak" yang sama kepada pemrogram, kode tidak boleh rusak.

Sekali lagi, jangan salah paham, Anda dapat menggunakan pembuat kueri untuk meminta tampilan, tetapi banyak tampilan muncul sebagai proses maduration yang merupakan produk harus menulis permintaan dan bertanya pada DBA Anda: "man, buat ini, tolong" .

Apakah saya salah dalam berpikir bahwa dengan tidak menulis pertanyaan, Anda gagal mendeteksi kebutuhan untuk menciptakan pandangan tertentu?

Hal lain yang menjadi perhatian saya adalah programmer pemula yang tidak menguasai SQL, salah satu teknologi paling indah yang diciptakan oleh manusia, dengan tidak harus melakukannya.


Bagaimana dengan DBA yang mengatakan, "Permintaan ini berjalan buruk, mari kita bekerja sama dan memperbaikinya." Awalnya mungkin bekerja dengan baik, tetapi sekarang mengalami masalah. Jika semua yang diperlukan hanyalah indeks, mengapa repot-repot dengan itu?
JeffO

Itu situasi yang benar-benar berbeda, dan sangat oke.
Tulains Córdova

Saya hanya merasa ingin melibatkan DBA setiap kali kueri menarik satu catatan dari tabel atau tampilan menciptakan hambatan dalam proses pengembangan.
JeffO
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.