Setiap pernyataan SQL harus ditinjau oleh DBA - umum?


11

Maksud saya segalanya, bukan hanya perubahan skema. Bahkan SELECT sederhana pada kunci primer tidak dapat masuk ke produksi, meskipun telah ditinjau kode oleh pengembang lain (dalam konteks), tanpa ulasan DBA dari setiap pernyataan, diekstraksi dari kode dan dikirimkan dengan output EXPLAIN, detail seberapa sering akan dipanggil, dll, dll.

Jika Anda berada di lingkungan seperti itu, apakah Anda menganggapnya sebagai keuntungan bersih, atau hambatan pada pengembangan? Sebagai seseorang yang telah bekerja dengan database relasional selama bertahun-tahun, saya menemukan sikap "pengembang tidak dapat dipercaya untuk menggunakan database" tidak beralasan, dan saya ingin tahu seberapa umum situasi ini. Untuk apa nilainya, ini hanya untuk pengembangan web, bukan sesuatu yang kritis.


2
Kami tidak memasukkan pernyataan SQL ke dalam kode. Namun, SEMUA kode harus ditinjau oleh individu berpengetahuan yang tepat.
CaffGeek

4
Pengembangan web sangat penting. Hasilnya langsung berhadapan dengan pelanggan (yang adalah rajamu), dan lebih sering daripada tidak, data sensitif dapat diakses ke server web.
thiton

2
Pertanyaannya adalah, jika tidak setiap permintaan dilewati oleh DBA, bagaimana Anda mendefinisikan apa yang harus dan tidak seharusnya dilewatkan oleh DBA?
programmer

6
@thiton: Itu pernyataan selimut dengan asumsi bahwa SEMUA aplikasi web menghadap ke publik dan merupakan aplikasi paling penting dalam organisasi. Itu tidak benar. Terkadang aplikasi web tingkat ketiga atau lebih rendah (dibandingkan dengan aplikasi lain). Beberapa hanya digunakan oleh tim internal kecil. Tanpa tahu apa yang sedang dikerjakan oleh @ DanEllis, kami benar-benar tidak tahu seberapa penting pekerjaan pengembangan web ini.
FrustratedWithFormsDesigner

2
Anda belum digigit? Pertimbangkan untuk bertanya mengapa prosedur ini ada ...

Jawaban:


15

Di salah satu pekerjaan saya sebelumnya, saya (bersama dengan tiga programmer lain) bertanggung jawab untuk meninjau setiap prosedur tersimpan yang dibuat atau diperbarui sebelum mulai diproduksi untuk sekitar 40+ programmer. Sebagai peninjau itu adalah hambatan nyata pada waktu saya, tetapi secara keseluruhan masih diperlukan karena dengan itu banyak pengembang akan membuat kesalahan sesekali. Itu terjadi karena kami memiliki programmer lepas pantai yang menulis pernyataan SQL yang benar-benar buruk (efisien) dan mereka menolak untuk belajar (tim itu akhirnya ditutup).

Secara keseluruhan kami mencari:

  • Penggunaan indeks - apakah permintaan melakukan pemindaian tabel penuh?
  • Maintainability - apakah permintaan akan perlu diubah dalam beberapa minggu karena ada sesuatu yang sulit dikodekan ke dalamnya? Dan apakah permintaan dapat dibaca?
  • Efisiensi keseluruhan - bisakah sebuah inner join diganti dengan yang ada? Apakah menambahkan blok Dengan membantu?
  • Mengunci masalah - apakah kueri akan mengunci basis data dan mencegah pembaruan terjadi? Ini terjadi lebih daripada yang saya pikirkan.

Lebih sering daripada tidak semua pertanyaan tidak memiliki masalah dan kami mendorongnya. Tetapi setiap tinjauan memakan waktu antara 10 menit dan dua jam tergantung pada kueri. Sebagian dari saya menyukai gagasan untuk melakukan tinjauan karena itu mencegah panggilan telepon pukul 2 pagi yang ditakuti karena beberapa laporan menyebabkan masalah dengan aplikasi lain. Tetapi pada saat yang sama saya pikir itu agak berlebihan karena kita semua sudah dewasa dan orang yang menulis kueri harus melakukan semua hal itu sendiri.

Saya pikir pertanyaan kompleks harus menjadi bagian dari tinjauan kode standar, tetapi tidak perlu melalui DBA. Juga tidak meninjau pernyataan menyisipkan / memperbarui / menghapus sederhana tidak diperlukan. Selain itu, sebagai penulis kueri, Anda harus tahu kapan permintaannya terlalu rumit dan tahu kapan harus meminta ulasan dari DBA.

Pembaruan Dalam pekerjaan pertama saya, semua pertanyaan ditulis oleh DBA dan itu adalah pembunuh waktu utama dalam pengembangan. Saya harus mengirimkan semua kolom yang saya inginkan, tabel tempat kolom berada dan akhirnya kriteria pencarian saya. Bahkan pernyataan dasar menyisipkan / memperbarui / menghapus perlu melalui DBA. Akhirnya saya sampai pada titik di mana saya bisa menulis SQL yang saya inginkan, minta mereka melihatnya dan membuat perubahan yang diperlukan, dan kemudian membungkus prosedur yang tersimpan di sekitarnya, tetapi itu hanya memiliki beberapa tahun di sana. Perusahaan tertentu itu mempekerjakan banyak lulusan perguruan tinggi baru-baru ini dan ini adalah cara mereka memastikan orang-orang baru tidak menulis pertanyaan yang membunuh kinerja.


-1 Sebuah jawaban yang bagus tapi sayangnya pertanyaannya adalah tentang review oleh dba setelah sesama review programmer. Jawaban ini benar-benar untuk pertanyaan "semua kode harus ditinjau" tetapi itu bukan pertanyaan yang diajukan. Saya tidak banyak downvote atau karena dendam, hanya ketika mereka menjawab bukan jawaban atas pertanyaan.
Michael Durrant

Persis. Ini adalah kode yang sudah ditinjau dalam konteks . Itu penting. Sebuah kueri yang terisolasi mungkin terlihat tidak berbahaya, tetapi menempatkannya di dalam satu lingkaran dan tiba-tiba kurang begitu.
Isvara

1
Apakah ada alat untuk mengotomatisasi hal semacam ini? Saya sedang memikirkan alat yang membuat rencana eksekusi untuk semua pertanyaan yang diajukan dan kemudian menandai apa pun dengan pindaian tabel lengkap atau produk Cartesian. Saya ragu itu bisa menangkap segalanya , tetapi mungkin akan mempercepat waktu peninjauan dan juga bisa dijalankan oleh pengembang melalui skrip, atau bahkan lebih baik jika dijalankan secara otomatis pada waktu kode masuk.
FrustratedWithFormsDesigner

10

Itu sepenuhnya tergantung pada lingkungan, industri dan perusahaan.

Beberapa contoh:

  • Di NASA, berbagai tingkat pemeriksaan dan peninjauan adalah standarnya. Yang paling terkenal "seharusnya diperiksa dua kali lipat" adalah ketika sebuah penyelidikan dikirim ke Mars dan AS melakukan perhitungan dengan berjalan kaki, tetapi orang-orang Eropa dalam meter. Probe hilang.

  • Pada startup tanpa DBA (umum hari ini) tidak akan ada review DBA dan bahkan mungkin tidak ada review programmer (misalnya, jika tidak ada programmer lain di perusahaan).

  • Di perusahaan yang produknya merupakan gudang data ratusan juta baris, memastikan bahwa kueri efisien dan benar dapat menjadi masalah utama pada inti bisnis yang harus diperiksa.

Perusahaan yang produk utamanya adalah situs web statis terutama dengan sejumlah kecil interaksi basis data, mungkin menganggap basis data dan efisiensinya kurang relevan. Mungkin saja perusahaan memilih untuk membelanjakan ulasannya "anggaran" pada halaman statis yang dianggap paling kritis.


5

Saya tidak pernah bekerja di lingkungan seperti itu, saya yakin saya akan membencinya. Sebuah pemikiran muncul di pikiran untuk mulai melacak beberapa metrik di sekitar ini ...

  • Berapa banyak waktu yang dihabiskan seorang pengembang untuk mengeluarkan sql dari kode dan mempersiapkannya untuk diserahkan ke DBA
  • Berapa lama DBA mengambil untuk meninjau sql?
  • Seberapa sering perubahan diminta oleh DBA? Dipecah berdasarkan
    jenis permintaan ?

Melacak ini hanya sebentar mungkin akan menunjukkan seberapa banyak hambatan dibandingkan seberapa efektif itu.


6
Ini adalah hal-hal luar biasa untuk diukur. Sementara Anda melakukannya, berapa banyak waktu yang dihabiskan untuk memperbaiki kode yang rusak yang diizinkan menjadi produksi? Berapa jam yang dibutuhkan Penjualan dan Pemasaran untuk menemukan pelanggan untuk menggantikan pelanggan yang hilang sementara situs Anda tidak berfungsi karena klausa WHERE yang terlewat menyebabkan pemindaian tabel berulang? Peninjauan kode memiliki biaya dan manfaat, jangan abaikan juga.

4
Itu sebabnya penting untuk mengetahui berapa kali perubahan diminta / dibutuhkan oleh DBA. Pertanyaannya secara eksplisit mengatakan bahwa semuanya ditinjau, tidak ada pengecualian. Kebijakan luas semacam ini yang biasanya memiliki biaya lebih banyak daripada manfaat. Saya seorang pendukung besar tinjauan kode dan pengujian tetapi tidak berarti bahwa setiap baris ditinjau atau diuji. Kita seharusnya menjadi profesional dan ada perbedaan antara kontrol kualitas dan pengasuhan bayi.
BZink

4

Kebanyakan pengembang tidak tahu apa-apa tentang database. Mereka bahkan tidak menyadari ketidaktahuan mereka. Saya dulu adalah seorang pengembang yang bodoh.

Pengembang hidup di dunia optimisasi-adalah-jahat. Pola pikir itu tidak berfungsi ketika Anda melakukan operasi terhadap disk. Pola pikir itu tidak berfungsi ketika Anda memilih tipe data yang 8 kali lebih besar daripada yang seharusnya yang menyebabkan indeks menjadi 8 kali lebih besar dari yang seharusnya sehingga tidak bisa lagi masuk ke dalam memori. Pola pikir itu tidak berfungsi ketika Anda memprogram melawan API generik yang secara berlebihan memperbarui semua kolom dalam sebuah tabel (tidak, terima kasih Java beans).

Mereka tidak tahu apa itu pemindaian tabel penuh. Mereka tidak tahu bagaimana memproses data dalam operasi set tunggal alih-alih membuka kursor. Lebih buruk daripada kursor, mereka akan meminta data, kemudian proses baris demi baris akan bolak-balik ke basis data ketika satu pembaruan sederhana-jane cukup. Menghasilkan kinerja HORRIBLE.

Mereka tidak tahu dampak serius dari pelaporan terhadap tabel besar. Mungkin kebutuhan akan laporan memerlukan pembuatan skema bintang dan umpan data ke dalamnya. Pengembang rata-rata Anda hanya akan menanyakan tabel yang ada dan bertanya-tanya mengapa dibutuhkan waktu 3 jam untuk menjalankan kueri (ini adalah angka sebenarnya).

Pengetahuan yang dimiliki pengembang rata-rata Anda sudah cukup untuk aplikasi CRUD "rata-rata" di mana pengguna hanya mengedit catatan. Itu tidak akan cukup setelah mereka keluar dari gelembung Ruby-on-Crack dan masuk ke dunia nyata.


Apakah Anda ingin terdengar lebih suci dari pada Anda?
sevenseacat

2
@Karpie, setidaknya dia mengambil waktu untuk merespons menggambar dari pengalamannya sendiri, daripada membuat komentar sarkastik yang tidak berharga pada jawaban orang lain seperti yang dilakukan Karpie.
Drew

2

Tergantung pada seberapa besar database, dan apakah itu dibagi di antara banyak aplikasi. Seringkali tim DBA suka mengetahui pertanyaan apa yang akan dijalankan sehingga mereka dapat memastikan bahwa indeks yang tepat sudah ada, atau mereka tahu siapa yang harus memberi tahu jika mereka harus mempartisi tabel. Dan mereka cenderung sedikit lebih baik daripada rata-rata pengembang dalam membaca rencana pelaksanaan kueri dan melihat tempat-tempat di mana petunjuk dapat ditentukan untuk meningkatkan kinerja. Ini juga merupakan kesempatan bagi mereka untuk mendapatkan informasi bahwa beberapa pertanyaan berdampak tinggi akan muncul di rilis berikutnya, sehingga mereka dapat mengumpulkan statistik berbeda untuk pengoptimal.


2

Saya belum bekerja di lingkungan seperti itu, saya juga tidak.

Ada perbedaan antara kerja tim dan birokrasi yang bermusuhan. Sebagai pengembang, saya ingin masukan DBA pada pertanyaan yang sulit. Tapi saya tahu kapan harus meminta bantuan.

Jika saya tidak cukup kompeten untuk SELECTpertanyaan sederhana , saya harus dipecat.


1
Meskipun itu adalah sudut pandang yang masuk akal, Anda harus mengizinkan bahwa kami sangat sedikit di antara kami yang secerdas yang ingin kami pikirkan dan para pelanggar terburuk adalah yang paling bodoh (hampir menurut definisi bukan mereka yang ada di sini) sehingga cara Anda menghindari masalahnya adalah dengan memiliki aturan selimut - semua orang memperlakukan sama
Murph

2
@ Murph - benar-benar. Saya bisa membuat kesalahan. Tapi saya juga bisa istirahat 2 jam di kamar mandi setiap hari. Haruskah setiap orang harus melacak waktu kamar mandi mereka untuk mencegahnya? Haruskah kita harus menandatangani formulir untuk mendapatkan penjepit kertas sehingga kita menghindari pencurian penjepit kertas? Pada titik tertentu, Anda harus memercayai orang atau memecat mereka. Permintaan saya yang lambat membutuhkan biaya, tetapi demikian pula proses peninjauan yang menghabiskan waktu dan menghabiskan banyak waktu. Hanya jika perbedaan kinerja basis data yang kecil akan menelan biaya jutaan (atau nyawa) saya akan menerima hal semacam ini.
Nathan Long

1
Masalahnya adalah Anda kemungkinan bukan pengembang biasa; dan sangat mungkin bukan pengembang masalah. Saya telah bekerja di tempat seperti ini, dan itu agak sial; tapi tahukah Anda DBA kami adalah orang-orang yang menerima telepon di tengah malam ketika pertanyaan pecah, bukan saya. Jika merekalah yang dianggap bertanggung jawab, mereka berhak meninjau kode yang menjadi tanggung jawab mereka.
Telastyn

@ Telastyn - "bukan pengembang biasa" Saya tidak membeli; Saya masih mengatakan jangan mempekerjakan pengembang yang buruk. Tapi ya, jika para DBA harus mendapat telepon, saya lebih bersimpati.
Nathan Long

@NathanLong tentang konteksnya - dalam konteks di mana Anda bekerja mungkin bukan masalah, pada orang lain jelas memiliki potensi untuk menjadi dan salah satu cara Anda menghindari masalah-masalah tertentu adalah dengan memiliki apa yang tampaknya menjadi aturan yang tidak ada artinya (meskipun , seperti fakta bahwa saya selalu menggunakan {} dalam pernyataan if saya, ini dilakukan untuk suatu tujuan). Itu buruk "karena saya tidak suka dan saya pikir saya aman sehingga tidak seharusnya berlaku untuk saya" adalah argumen yang dipertanyakan (logika yang sama diterapkan untuk mengabaikan batas kecepatan). Hmm, itu argumentatif) -: Maaf.
Murph

2

Saya telah melihat ini dilakukan di beberapa tempat yang berbeda. Ini hebat dalam teori, tetapi saya jarang melihatnya efektif. Inilah sebabnya. Pertama, jika Anda memiliki tim DBA (atau orang lain), saya secara umum menemukan bahwa orang yang paling tidak kompeten atau paling tidak disukai dalam kelompok mendapat beban pekerjaan peninjauan. Kenapa, katamu? Itu karena, tidak ada orang lain yang mau melakukannya, dan semua orang sibuk melakukan hal-hal lain yang mungkin lebih mendesak. Pernah melihat DBA duduk dan berkata, "Man semuanya berjalan sempurna; Saya hanya bisa duduk dan berselancar di internet. Saya berharap saya memiliki sesuatu untuk dilakukan." Saya juga, setidaknya bukan yang baik. Mereka sibuk atau lebih sibuk daripada orang lain. Ini berarti bahwa orang yang paling tidak cakap kemungkinan besar melakukan peninjauan, dan ini adalah orang yang sebenarnya tidak Anda inginkan. Kode yang ingin Anda tinjau adalah kode yang benar-benar sulit yang dilihat orang dan menganggapnya sebagai semacam ilmu hitam. DBA junior atau hanya yang buruk, tidak akan pernah bisa menangkap seluk-beluk bagaimana kueri yang sangat sulit bekerja. Jarang, seperti tidak pernah, ada orang yang berkata, "Astaga, saya tidak berpikir untuk memilih satu baris pun dari sebuah meja menggunakan kunci utama! Terima kasih DBA Anda seorang penyelamat." Jadi dalam skenario ini, sebenarnya yang Anda lakukan adalah menciptakan banyak pekerjaan dengan nilai kecil. jangan berpikir untuk memilih satu baris dari tabel menggunakan kunci utama! Terima kasih DBA, Anda penyelamat. "Jadi dalam skenario ini, sebenarnya yang Anda lakukan adalah menciptakan banyak pekerjaan dengan nilai kecil. jangan berpikir untuk memilih satu baris dari tabel menggunakan kunci utama! Terima kasih DBA, Anda penyelamat. "Jadi dalam skenario ini, sebenarnya yang Anda lakukan adalah menciptakan banyak pekerjaan dengan nilai kecil.

Kedua, ini hanya pekerjaan biasa bagi kelompok DB. Apa yang mungkin akan terjadi bahkan jika mereka melihat hal-hal lain adalah mereka akan memeriksanya dan ada sesuatu yang akan terlewatkan. Mereka adalah orang-orang yang sibuk, dan meninjau kode sangat memakan waktu. Sebenarnya itu tidak adil bahwa mereka mendapatkan tugas dengan ini, karena itu alasan bagi semua orang untuk malas dan menggunakannya sebagai jalan keluar, yang pada akhirnya itulah yang terjadi. Sesuatu rusak dalam produksi, dan pengembang dengan cepat menunjukkan, "Yah, DBA memeriksanya." Sekarang apakah ini benar setiap saat, tidak, tetapi itu adalah sebagian waktu dan sering dari orang-orang yang perlu memiliki kode mereka benar-benar ditinjau. Jadi Anda telah mengubur DBA dengan pekerjaan ekstra dan memaksa orang itu untuk bertanggung jawab atas kesalahan orang lain, ketika orang itu mungkin tidak melakukannya

Satu-satunya cara untuk benar-benar menyelesaikan masalah adalah memiliki orang yang tahu cara menulis kode SQL menulisnya. Haruskah mereka mendapatkan input dari DBA dari waktu ke waktu? Tentu saja mereka harus, tetapi saya selalu menemukan, jika Anda tidak punya waktu untuk melakukannya dengan benar pertama kali, kapan Anda akan menemukan waktu untuk memperbaikinya.


2

Saya telah bekerja di lingkungan semacam itu. Semua perubahan sistem ditinjau oleh rekan sejawat yang sesuai. Bagi saya itu hanya berarti saya harus merencanakan ke depan dan mengirimkan perubahan saya beberapa hari sebelumnya. SQL pergi ke DBA yang pada akhirnya akan merilis SQL ke dalam produksi.

SQL saya biasanya baik-baik saja, mereka menangkap beberapa kesalahan konyol. Awalnya terasa terlalu birokratis, tetapi saya bekerja di bidang keuangan. Anda melihat apa yang terjadi (Jika Anda berada di Inggris) beberapa bulan yang lalu ketika sebuah bank besar di sini mengacaukan peningkatan rutin dan mengacaukan semua transaksi yang menghasilkan jutaan (Setidaknya ratusan ribu) orang yang tidak dapat memperoleh atas uang mereka.


0

Saya bahkan akan melangkah lebih jauh. Saya akan memeriksa kode di sekitarnya dan melihat bagaimana variabel diteruskan ke kueri. Seringkali untuk melihat bagaimana pengembang mengekspos aplikasi mereka ke serangan injeksi sql karena kurangnya pengetahuan dasar mereka ("ini tidak dapat diretas" asumsi palsu).

Pengembang yang tidak berpengalaman juga dapat menyeret database hingga berlutut dengan penyalahgunaan ORM atau kueri yang jauh dari optimal.

Dalam proyek terbaru saya bekerja, tidak ada pengembang front-end diizinkan untuk mengakses database secara langsung. Mereka meningkatkan permintaan untuk fungsi mengembalikan set data yang diberikan dan pengembang back-end menyiapkannya untuk mereka. Ini bekerja cukup baik, pengembang front-end menulis UI dan memproses data yang disediakan oleh fungsi yang ditulis oleh pengembang back-end.


0

Dalam tim pengembangan kami, ada sub-tim dari 4 Pengembang Database yang berpengalaman dalam platform DBMS yang kami gunakan. Mereka menulis semua SQL atau setidaknya ulasan dan membuat perubahan untuk memenuhi standar pengkodean mereka setiap SQL yang ditulis oleh pengembang Net. Mereka adalah bagian dari tim proyek. DBA produksi milik departemen yang sama sekali berbeda dan pekerjaan mereka operasional. Mereka tidak meninjau kode atau skema SQL kami dan bahkan penyebarannya dibuat skrip, yang mereka lakukan hanyalah menjalankan skrip. Yang paling mereka bantu adalah penyetelan kinerja.

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.