Memformat kode pertanyaan SQL


17

Haruskah saya memecah query SQL di baris yang berbeda? Misalnya dalam proyek yang saya kerjakan, kami memiliki permintaan yang mengambil 1.600 kolom! 1600 + karakter tab. Saya menulis pertanyaan seperti ini:

   "SELECT bla , bla2 , bla FROM bla " . 
     "WHERE bla=333 AND bla=2" . 
      "ORDER BY nfdfsd ...";

Tetapi mereka meminta saya untuk menempatkan mereka dalam satu baris dan mengatakan bahwa gaya saya berformat buruk. Mengapa itu praktik yang buruk?


Keberatan mungkin untuk penggunaan kutipan interpolasi (tanda kutip ganda) dan rangkaian ( .), yang saya lihat beberapa programmer menyalahkan untuk biaya kinerja.
Bruce Alderson

3
Semuanya harus dalam 1 baris? Hello scroll bar, mudah dibaca.
mike30

1
@BruceAlderson Kedengarannya seperti salah satu dari awal 2000-an "Ibu Rumah Tangga menemukan 3 tips sederhana untuk mengoptimalkan PHP Anda" artikel. Bendera merah asli dengan tanda kutip ganda dan / atau gabungan muncul ketika Anda mulai memasukkan variabel tanpa benar-benar keluar dari mereka membuat serangan injeksi SQL.
Sean McSomething

1
Apakah ada alat "in-house" yang digunakan untuk memproses file?
Ian

Mengapa sangat sulit untuk memahami bahwa selama Anda dibayar untuk kode, Anda harus menulis, bersih, rapi, kode tertib?
Tulains Córdova

Jawaban:


33

Untuk alasan kontrol sumber, kami memiliki linebreak setelah setiap klausa tempat, atau koma. Jadi di atas Anda berubah menjadi

SELECT bla 
     , bla2 
     , bla 
FROM   bla 
WHERE  bla=333 
  AND  bla=2
ORDER  BY nfdfsd
        , asdlfk;

(tab dan penyelarasan tidak memiliki standar di sini, tetapi koma biasanya memimpin)

Namun, tidak ada perbedaan kinerja.


5
Ide bagus, ini akan membuat perubahan kecil menonjol dengan sangat baik dalam kontrol sumber berbeda.
Carson63000

Cukup banyak format yang sama seperti yang saya gunakan, meskipun saya biasanya meletakkan semua daftar pilih pada satu baris (atau beberapa baris jika ada banyak kolom)
Dean Harding

7
Tata letak yang serupa di sini, hanya perbedaannya adalah koma terkemuka, kita memilikinya di akhir.
DBlackborough

4
@ m.edmondson - Perbedaan antara versi dalam kontrol sumber menyoroti perubahan pada basis per baris. Dengan format ini, setiap baris berisi sedikit informasi - nama kolom, nama tabel, klausa join atau order - yang berarti bahwa diff akan menunjuk tepat pada apa yang diubah, tidak hanya ke baris dengan banyak hal aktif dan meninggalkan Anda untuk mencari tahu apa yang berbeda.
Jon Hopkins

2
Format ini juga memudahkan untuk mengomentari item tunggal selama pengembangan dan menggunakan cut and paste untuk mengubah pemesanan.
Chris Nava

14

Kueri yang 1.600 kolom sepertinya membutuhkan ulasan serius oleh DBA yang bagus.

Jika kueri rumit, saya akan membungkusnya. Jika itu mudah saya akan meninggalkannya sebagai satu baris kecuali itu akan terlalu lama, maka saya akan mulai membungkusnya lagi.

Ini semua tentang pengelolaan dan memahami apa yang seharusnya dilakukan sehingga membungkus atau tidak membungkus dapat diputuskan dengan cepat, kecuali jika organisasi Anda memiliki beberapa aturan pemformatan kode tentang hal itu.

Re: itu menjadi praktik pengkodean yang buruk. Sulit! Ini latihan yang sangat bagus. Tidak ada alasan bagus yang saya tahu untuk menggunakan kueri selama itu, dan banyak alasan bagus untuk memformatnya kembali. Seperti yang saya katakan sebelumnya, DBA yang terampil mungkin perlu mengerjakannya.


3
Setuju, itu semua bermuara pada keterbacaan benar-benar. Kinerja dll tidak terpengaruh oleh ini sama sekali, itu semua hanya estetika.
Christian

Setuju bahwa kinerja tidak bisa menjadi argumen yang bagus.
the Tin Man

Saya tidak tahu .. hanya mengatakan kepada saya untuk menyimpannya dalam satu baris, mungkin karena mereka melakukannya
GorillaApe

Mereka mungkin takut menyentuhnya jika itu kode "lawas". Perlahan mundur dan semuanya akan baik-baik saja.
the Tin Man

Kode
barunya

8

Satu-satunya keuntungan dari kueri baris tunggal yang terlintas dalam pikiran adalah bahwa kueri tersebut mungkin lebih mudah untuk dipahami. Selain itu, saya bingung. Secara pribadi, saya lebih suka pertanyaan yang lebih mudah dibaca dan dibagi.


6

Komentar multiline baik, hampir vital ketika berhadapan dengan SQL dalam jumlah besar. Dan jika bahasa pemrograman Anda memiliki tanda kutip heredoc, itu lebih baik (karena banyak editor dapat menyoroti sintaks SQL di dalamnya).

Contoh:

$a = SQL<<<
    SELECT a, b, c, d
    FROM Foo f
    WHERE f.a = ?
SQL;

Ketika bekerja dengan permintaan puluhan baris (atau ratusan) baik lekukan dan spasi putih membuat teks bisa dikerjakan.


1
Untuk PHP, nowdocs adalah varietas yang dikutip tunggal (yaitu tidak ada substitusi variabel).
Alan Pearce

4

Tampaknya ini khusus tentang mendefinisikan kueri besar di dalam semacam bahasa pemrograman, melihat Anda memasukkan kueri ke dalam string literal dan menyatukannya.

Jika ini adalah bahasa yang dikompilasi, seharusnya tidak ada bedanya sama sekali - salah satu optimasi pertama yang dilakukan oleh kompiler adalah secara otomatis menggabungkan string string bersama-sama, jadi Anda berakhir dengan string besar.

Adapun sintaksnya, Anda seharusnya mempertimbangkan untuk memindahkan kueri di luar kode Anda - menyimpannya dalam file sumber daya .sql yang terpisah, dan minta perangkat lunak Anda membaca file itu. Gunakan pernyataan disiapkan untuk variabel, jika itu bukan permintaan yang dibangun secara dinamis (yaitu di mana-klausa dll ditambahkan tergantung pada parameter tertentu). Jika dibangun secara dinamis, Anda dapat menambahkan variabel pengganti Anda sendiri, memasukkan parameter tambahan di mana dan kapan diperlukan.

Adapun 1.600 kolom, saya sangat merekomendasikan membangun tampilan untuk itu, jadi alih-alih

SELECT column1, column2, .... column1600 from X where Y

kamu akan mendapatkan

PILIH * DARI viewX WHERE y

Jauh lebih ringkas dalam kode Anda sendiri.


+1, dan saya juga mempertimbangkan untuk membuat kueri menjadi prosedur tersimpan
Larry Coleman

1

Saya sering menggunakan format yang diajukan oleh @glasnt untuk memecahkan masalah kueri yang rumit, namun biasanya memiliki kueri dalam satu baris.

Ini mungkin tidak menjawab pertanyaan Anda, tetapi saya juga sangat menyarankan memecah permintaan Anda menjadi pertanyaan yang lebih kecil. Jelas ini tergantung pada kueri, tetapi semakin banyak klausa dan gabungan yang Anda tambahkan ke kueri Anda - semakin sedikit mesin SQL yang dapat mengoptimalkan kueri Anda.

Vendor basis data Anda harus memiliki alat seperti EXPLAIN MySQL (atau pengaturan SHOWPLAN_ALL MSSQL) yang akan menunjukkan kepada Anda apa yang dilakukan database di belakang layar untuk mengoptimalkan kueri Anda, setiap kali database harus membuat tabel sementara atau semacamnya, Anda menambahkan penundaan besar ketika Anda berbicara tentang banyak pengguna secara bersamaan.

Dengan memindahkan apa yang tampak seperti logika sepele dari SQL dan ke dalam kode Anda, Anda dapat memberikan peningkatan kinerja yang dramatis - SQL sangat bagus dalam operasi sederhana.

Manfaat yang jelas untuk ini karena mungkin berhubungan dengan Anda, adalah bahwa pertanyaan Anda jauh lebih kompleks dan mudah dibaca - mudah dikelola (tidak> 1.600 kolom), dan lebih cepat. Jelas merupakan kemenangan serba.

Semoga ini membantu :)

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.