Setiap pernyataan SQL harus ditinjau oleh DBA - umum?

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.