Her SQL ifadesi bir DBA tarafından gözden geçirilmelidir - ortak mı?

Her şey demek istiyorum, sadece şema değişimleri değil. Bir birincil anahtardaki basit bir SELECT bile, her geliştiricinin (bağlamda) kod incelemesi yapılmasına rağmen, her ifadenin DBA incelemesi yapılmadan, koddan çıkarılıp EXPLAIN çıktısıyla gönderilmesine rağmen ayrıntılar üretilemez, ayrıntılar ne sıklıkta çağrılacağı, vb.

Eğer böyle bir ortamda bulunduysanız, bunun net bir kazanç mı, yoksa gelişme üzerinde bir sürükleme olduğunu mu buldunuz? İlişkisel veritabanlarıyla yıllardır çalışan biri olarak, "geliştiricilerin veritabanlarını kullanmalarına güvenilemez" tutumunu gereksiz buluyorum ve bu durumun ne kadar yaygın olduğunu merak ediyorum. Değer için, bu sadece web geliştirme içindir, kritik bir şey değildir.

Önceki işlerimden birinde (diğer üç programcı ile birlikte), 40'tan fazla programcı için üretime geçmeden önce oluşturulan veya güncellenen her saklı prosedürü gözden geçirmekle sorumluydum. Bir gözden geçiren olarak benim zaman gerçek bir sürükle oldu ama genel olarak hala gerekli çünkü birçok geliştirici arada bir hata yapacak. Çünkü gerçekten kötü (verimli bilge) SQL ifadeleri yazan kıyı programcılarımız vardı ve öğrenmeyi reddetti (bu takım sonunda kapatıldı).

Genel olarak aradık:

• Dizin kullanımı - sorgu tam tablo taraması yapıyor muydu?
• Sürdürülebilirlik - Sorgunun içine bir şey kodlandığı için birkaç hafta içinde değiştirilmesi gerekecek miydi? Ve sorgu okunabilir mi?
• Genel verimlilik - bir iç birleşim bir varlıkla değiştirilebilir mi? Bir blokla ekleme yardımcı olur mu?
• Kilitleme sorunları - sorgu veritabanını kilitler ve güncellemelerin olmasını engeller mi? Bu düşündüğümden daha fazla oldu.

Çoğu sorgudan daha sık hiçbir sorun yoktu ve biz onu itti. Ancak her inceleme sorguya bağlı olarak 10 dakika ile iki saat arasında sürdü. Bir kısmı, bazı raporların başka bir uygulamayla ilgili bir soruna neden olduğu için korkunç 2 AM telefon görüşmesini engellediğinden yorum yapma fikrini beğendim. Ama aynı zamanda bunun biraz abartılı olduğunu düşündüm çünkü hepimiz yetişkiniz ve sorguyu yazan kişi tüm bu şeyleri kendileri yapmalıdır.

Karmaşık sorgular standart kod inceleme bir parçası olması gerektiğini düşünüyorum, ama bir DBA geçmesi gerekmez. Ayrıca, basit ekleme / güncelleme / silme ifadelerini incelemenize gerek yoktur. Buna ek olarak, bir sorgunun yazarı olarak sorgunun ne zaman çok karmaşık hale geldiğini ve bir DBA'dan ne zaman inceleme isteyeceğini bilmelisiniz.

Güncelleme İlk işimde tüm sorgular DBA'lar tarafından yazıldı ve bu geliştirme konusunda büyük bir zaman katiliydi. İstediğim tüm sütunları, sütunların bulunduğu tabloları ve son olarak arama ölçütlerimi göndermek zorunda kaldım. Hatta bir DBA'dan geçmek için temel ekleme / güncelleme / silme ifadeleri bile gerekiyordu. Sonunda istediğim SQL'i yazabileceğim, onlara bir göz atmalarını ve gerekli değişiklikleri yapmalarını sağladım ve sonra saklı bir prosedürü sardım, ama bu sadece birkaç yıl oldu. Bu şirket yakın zamanda birçok üniversite mezunu işe aldı ve bu, yeni adamların performansı öldüren sorgular yazmadığından emin olmalarıydı.

Tamamen çevreye, sektöre ve şirkete bağlıdır.

Bazı örnekler:

• NASA'da, çoklu kontrol ve gözden geçirme seviyeleri standarttır. En tanınmış "iki kat kontrol edilmeliydi" Mars'a bir soruşturma gönderildiğinde ve ABD'nin ayak cinsinden hesaplamalar yaptığı, ancak Avrupalıların metre cinsinden olduğu zamandı . Prob kayboldu.

• DBA'sı olmayan bir başlangıçta (bu günlerde yaygın), DBA incelemesi ve hatta muhtemelen programcı incelemesi olmayacaktır (örneğin, şirkette başka programcı yoksa).

• Ürünü yüz milyonlarca satırlık bir veri ambarı olan bir şirkette, sorguların verimli ve doğru olduğundan emin olmak, işletmenin özünde kontrol edilmesi gereken önemli konular olabilir.

Ana ürünü az sayıda veritabanı etkileşimi olan esas olarak statik bir web sitesi olan bir şirket, veritabanının ve verimliliğinin daha az alakalı olduğunu düşünebilir. Şirket, gözden geçirme "bütçesini" en kritik kabul edilen statik sayfalarda harcamayı seçebilir.

Daha önce hiç böyle bir ortamda çalışmadım, eminim nefret ederdim. Bu konuda bazı metrikleri takip etmeye başlamak için bir düşünce akla geliyor ...

• Bir geliştirici sql'yi koddan çıkararak ve onu bir DBA'ya sunulmaya hazırlayarak ne kadar zaman harcıyor?
• DBA'nın sql'yi incelemesi ne kadar sürer?
• DBA tarafından ne sıklıkla değişiklik isteniyor? Sorgu
  türüne göre ayrılmış mı?

Bunu bir süreliğine takip etmek, ne kadar etkili olduğunu ve ne kadar etkili olduğunu gösterecektir.

Çoğu geliştirici, veritabanları söz konusu olduğunda cahildir. Cehaletlerinin farkında bile değiller. Eskiden cahil bir geliştiriciydim.

Geliştiriciler, optimizasyon-kötülük dünyasında yaşarlar. Bir diske karşı işlemler gerçekleştirirken bu zihniyet çalışmaz. Bu zihin seti, olması gerekenden 8 kat daha büyük bir veri türü seçtiğinizde çalışmaz, bu da dizinin olması gerekenden 8 kat daha büyük olmasına neden olur, böylece artık belleğe sığmaz. Bu zihniyet, bir tablodaki tüm sütunları yedekli olarak güncelleyen genel bir API'ye karşı programladığınızda çalışmaz (teşekkürler Java çekirdekleri).

Tam masa taramasının ne olduğunu bilmiyorlar. Verileri bir imleç açmak yerine tek bir set işleminde nasıl işleyeceklerini bilmiyorlar. Bir imleçten daha kötüsü, verileri sorgulayacaklar, daha sonra tek bir basit düz-jane güncellemesi yeterli olduğunda veritabanına ileri geri veriyordu. HORRIBLE performansıyla sonuçlanır.

Büyük tablolara karşı raporlamanın ciddi etkilerini bilmiyorlar. Belki de raporlara duyulan ihtiyaç bir yıldız şeması ve içine bir veri akışı oluşturmayı gerektirecektir. Ortalama geliştiriciniz sadece exisitng tablolarını sorgular ve sorgunun neden 3 saat sürdüğünü merak eder (bu gerçek bir rakamdır).

Ortalama geliştiricinizin sahip olduğu bilgi, bir kullanıcının yalnızca bir kaydı düzenlediği "ortalama" CRUD uygulamaları için yeterli olacaktır. Ruby-on-Crack balonundan ve gerçek dünyaya girdikten sonra yeterli olmayacak.

Veritabanının ne kadar büyük olduğuna ve birden fazla uygulama arasında paylaşılıp paylaşılmadığına bağlıdır. DBA ekibi genellikle hangi sorguların çalıştırılacağını bilmek ister, böylece uygun dizinlerin yerinde olmasını sağlayabilirler ya da bir tabloyu bölümlemek zorunda kaldıklarında kime bildireceklerini bilirler. Ve sorgu yürütme planlarını okuma ve performansı iyileştirmek için ipuçlarının belirtilebileceği yerleri tespit etme konusunda ortalama geliştiriciden biraz daha iyi olma eğilimindedirler. Ayrıca, bazı yüksek etkili sorguların bir sonraki sürümde geleceği konusunda kafa yorma şansı da var, böylece optimize edici için farklı istatistikler toplayabilirler.

Ben böyle bir ortamda çalışmadım, ben de yapmam.

Ekip çalışması ve düşmanca bürokrasi arasında bir fark vardır. Bir geliştirici olarak, zor sorgularda DBA girdisine sahip olmak isterim. Ama ne zaman yardım isteyeceğimi biliyorum.

Basit SELECTsorgular için yeterince yetkin değilsem işten çıkarılmalıyım.

Bunun birkaç farklı yerde yapıldığını gördüm. Teoride harika, ama nadiren etkili olduğunu gördüm. İşte nedeni. İlk olarak, bir DBA ekibiniz (veya başka kişiler) varsa, genellikle grubun en az yetkin veya en az sevilen kişinin inceleme çalışmasının yükünü aldığını buldum. Neden öyle dedin? Çünkü başka hiç kimse bunu yapmak istemez ve diğer herkes muhtemelen daha acil olan diğer şeyleri yapmakla meşguldür. DBA'nın etrafta oturup “Adam her şey mükemmel gidiyor; sadece arkanıza yaslanıp internette sörf yapabilirim. Yapacak bir şeyim olsaydı” dedim. Ben de, en azından iyi olanlar da değil. Herkesten daha meşgul ya da daha meşguller. Bu, en az yetenekli olan kişinin büyük olasılıkla incelemeyi yaptığı anlamına gelir ve bu tam olarak bunu yapmak istemediğiniz kişidir. Gözden geçirilmesini istediğiniz kod, insanların bir tür kara büyü olarak baktığı ve geçtiği gerçekten zor koddur. Junior DBA'lar veya sadece kötü olanlar, gerçekten zor bir sorgunun nasıl çalıştığının inceliklerini yakalayamayacak. Nadiren, hiç olmadığı gibi, "Adam birincil tabloyu kullanarak tablodan tek bir satır seçmeyi düşünmedim! Teşekkürler DBA cankurtaransın." Yani bu senaryoda, gerçekte yaptığınız tek şey az değer için çok fazla iş yaratmak. t Birincil anahtarı kullanarak tablodan tek bir satır seçmeyi düşünmeyin! Teşekkürler DBA cankurtaransın. "Yani bu senaryoda, gerçekte yaptığınız tek şey çok az değer için çok iş yaratmak. t Birincil anahtarı kullanarak tablodan tek bir satır seçmeyi düşünmeyin! Teşekkürler DBA cankurtaransın. "Yani bu senaryoda, gerçekte yaptığınız tek şey çok az değer için çok iş yaratmak.

İkincisi, DB grubu için sadece daha fazla iş. Muhtemelen başka şeylere baksalar bile olacaklar, ona hızlı bir şekilde bakacaklar ve bir şeyler kaçırılacaklar. Meşgul insanlar ve kodu gözden geçirmek gerçekten zaman alıcı. Gerçekte, bununla görevlendirilmeleri adil değildir, çünkü diğerlerinin tembel olması ve onları bir çıkış olarak kullanması bir bahane, sonuçta ne olur. Üretimde bir şeyler kopuyor ve geliştirici hızla "DBA bunu gözden geçirdi." Şimdi bu her zaman doğru, hayır, ama zamanın gerçek bir parçası ve çoğu zaman kodlarının gerçekten gözden geçirilmesi gereken insanlardan. DBA'yı ekstra bir iş ile gömdünüz ve bu kişiyi muhtemelen başka birinin hatalarından sorumlu olmaya zorladınız.

Sorunu gerçekten çözmenin tek yolu, SQL kodunu nasıl yazacağını bilen kişilerin yazmasını sağlamaktır. Zaman zaman DBA'lardan girdi almalılar mı? Tabii ki yapmalılar, ama her zaman buldum, eğer ilk seferde doğru yapmak için zamanınız yoksa, düzeltmek için ne zaman bulacaksınız?

Bu tür bir ortamda çalıştım. Tüm sistem değişiklikleri uygun akranlar tarafından akran tarafından gözden geçirildi. Benim için sadece önceden planlamak ve değişikliklerimi birkaç gün önceden göndermek zorunda kaldım. SQL, sonuçta SQL'i üretime sokacak olan DBA'lara gitti.

SQL'im genellikle iyi, birkaç aptalca hata yakaladılar. İlk başta aşırı bürokratik hissettiriyor, ancak finans alanında çalışıyorum. Birkaç ay önce, burada büyük bir banka rutin bir yükseltme yaptığında ve milyonlarca (en az yüz binlerce) insanın alamadığı tüm işlemleri bozduğunda ne olduğunu gördünüz (İngiltere'de iseniz) paralarında.

Hatta daha ileri giderdim. Etraftaki kodu kontrol ediyorum ve değişkenlerin sorguya nasıl geçtiğini görüyorum. Çoğu zaman, geliştiricilerin temel bilgi eksikliği nedeniyle uygulamalarını nasıl sql enjeksiyon saldırılarına maruz bıraktıklarını görmek ("bu saldırıya uğramaz" yanlış varsayımlar).

Ayrıca deneyimsiz geliştiriciler, ORM kötüye kullanımı veya optimalden uzak bir sorgu ile veritabanını dizlerine sürükleyebilirler.

Çalıştığım en son projede, hiçbir ön uç geliştiricinin veritabanına doğrudan erişmesine izin verilmiyor. Belirli bir veri kümesini döndüren bir işleve olan talebi artırırlar ve arka uç geliştiricileri bu verileri onlar için hazırlar. Oldukça iyi çalışıyor, ön uç geliştiriciler UI yazıyor ve arka uç geliştiriciler tarafından yazılan işlevler tarafından sağlanan işlem verilerini sağlıyor.

Geliştirme ekibimizde kullandığımız DBMS platformunda deneyimli 4 Veritabanı Geliştiricisinden oluşan bir alt ekip bulunmaktadır. Tüm SQL veya en azından incelemeleri yazarlar ve .Net geliştiricileri tarafından yazılan herhangi bir SQL kodlama standartlarını karşılamak için değişiklikler yaparlar. Bunlar proje ekibinin bir parçasıdır. Üretim DBA'ları tamamen farklı bir departmana aittir ve görevleri faaliyete geçmiştir. SQL kodumuzu veya şemamızı gözden geçirmezler ve hatta dağıtım komut dosyasıdır, tek yaptıkları komut dosyasını çalıştırmaktır. En çok yardımcı oldukları performans ayarlamasıdır.