Każda instrukcja SQL musi zostać przejrzana przez DBA - często?

Mam na myśli wszystko, nie tylko zmiany schematu. Nawet prosty WYBÓR na kluczu podstawowym nie może przejść do produkcji, mimo że został sprawdzony przez innych programistów (w kontekście), bez recenzji DBA każdej instrukcji, wyodrębnionej z kodu i przesłanej z danymi wyjściowymi EXPLAIN, szczegóły jak często będzie się nazywać, itp. itp.

Jeśli byłeś w takim środowisku, czy uważasz, że jest to zysk netto, czy utrudnienie w rozwoju? Jako osoba, która od lat pracuje z relacyjnymi bazami danych, uważam, że postawa „programiści nie mogą ufać w korzystaniu z baz danych” jest nieuzasadniona i jestem ciekawy, jak częsta jest ta sytuacja. Co jest warte, jest to tylko do tworzenia stron internetowych, a nie coś krytycznego.

Na jednym z moich wcześniejszych zadań ja (wraz z trzema innymi programistami) byłem odpowiedzialny za przejrzenie każdej procedury przechowywanej utworzonej lub zaktualizowanej przed wejściem do produkcji dla około 40 programistów. Jako recenzent miałem duży kłopot z moim czasem, ale ogólnie był on nadal potrzebny, ponieważ dzięki temu wielu programistów popełni błąd. Stało się tak, ponieważ mieliśmy programistów off-shore, którzy pisali naprawdę złe (wydajne) mądre instrukcje SQL i stanowczo odmówili nauki (zespół został ostatecznie zamknięty).

Ogólnie szukaliśmy:

• Użycie indeksu - czy zapytanie wykonało pełny skan tabeli?
• Utrzymywalność - czy zapytanie będzie musiało zostać zmienione w ciągu kilku tygodni, ponieważ coś było w nim zakodowane? Czy zapytanie jest czytelne?
• Ogólna wydajność - czy połączenie wewnętrzne można zastąpić istniejącym? Czy dodanie pomocy Z blokiem?
• Problemy z blokowaniem - czy zapytanie zablokuje bazę danych i uniemożliwi aktualizacje? Stało się to bardziej, niż mi się wydaje.

Najczęściej większość zapytań nie miała problemów i dlatego kontynuowaliśmy. Ale każda recenzja trwała od 10 minut do dwóch godzin, w zależności od zapytania. Części mnie podobał się pomysł robienia recenzji, ponieważ zapobiegał on przerażającemu połączeniu telefonicznemu o 2 nad ranem, ponieważ niektóre raporty powodowały problem z inną aplikacją. Ale jednocześnie pomyślałem, że to trochę przesada, ponieważ wszyscy jesteśmy dorośli, a osoba pisząca zapytanie powinna sama to wszystko zrobić.

Myślę, że złożone zapytania powinny być częścią standardowego przeglądu kodu, ale nie muszą przechodzić przez DBA. Również przeglądanie prostych instrukcji wstawiania / aktualizacji / usuwania nie jest potrzebne. Ponadto, jako autor zapytania, powinieneś wiedzieć, kiedy stało się ono zbyt skomplikowane i wiedzieć, kiedy poprosić o recenzję DBA.

Aktualizacja W mojej pierwszej pracy wszystkie zapytania zostały napisane przez DBA i było to głównym zabójcą czasu na rozwoju. Musiałem przesłać wszystkie kolumny, które chciałem, tabele, w których kolumny zostały umieszczone, i wreszcie moje kryteria wyszukiwania. Nawet podstawowe instrukcje wstawiania / aktualizacji / usuwania potrzebne były do ​​przejścia przez DBA. W końcu doszedłem do punktu, w którym mogłem napisać SQL, który chciałem, popatrzeć na niego i dokonać niezbędnych zmian, a następnie owinąć procedurę przechowywaną, ale było to tylko kilka lat. Ta konkretna firma zatrudniła wielu absolwentów szkół wyższych i właśnie w ten sposób upewnili się, że nowi faceci nie piszą zapytań, które zabiły ten występ.

Zależy to całkowicie od środowiska, branży i firmy.

Kilka przykładów:

• W NASA standardem jest wiele poziomów sprawdzania i recenzowania. Najbardziej znanym „powinienem podwójnie sprawdzić” było wysłanie sondy na Marsa i USA wykonały obliczenia w stopach, ale Europejczycy w metrach. Sonda została zgubiona.

• Na starcie bez DBA (obecnie często) nie będzie przeglądu DBA, a być może nawet przeglądu programisty (na przykład, jeśli w firmie nie ma innych programistów).

• W firmie, której produktem jest hurtownia danych obejmująca setki milionów wierszy, upewnienie się, że zapytania są wydajne i poprawne, może być kluczowym zagadnieniem leżącym u podstaw działalności, który należy sprawdzić.

Firma, której głównym produktem jest głównie statyczna strona internetowa z niewielką liczbą interakcji z bazą danych, może uznać bazę danych i jej wydajność za mniej istotną. Możliwe, że firma zdecyduje się wydać „budżet” na statyczne strony, które są uważane za najbardziej krytyczne.

Nigdy nie pracowałem w takim środowisku, jestem pewien, że bym go nienawidził. Przychodzi mi na myśl myśl, aby zacząć śledzić niektóre wskaźniki wokół tego ...

• Ile czasu deweloper spędza, wyciągając kod SQL z kodu i przygotowując go do przesłania do DBA
• Jak długo trwa sprawdzanie kodu SQL przez DBA?
• Jak często DBA żąda zmian? W podziale według
  typu zapytania ?

Śledzenie tego przez krótką chwilę prawdopodobnie pokaże, jak duży jest opór w porównaniu do jego skuteczności.

Większość programistów jest całkowicie nieświadoma, jeśli chodzi o bazy danych. Nie są nawet świadomi swojej ignorancji. Sam byłem kiedyś nieświadomym programistą.

Programiści żyją w świecie optymalizacji zła. Ten sposób myślenia nie działa, gdy wykonujesz operacje na dysku. Ten zestaw myśli nie działa, gdy wybierzesz typ danych, który jest 8 razy większy niż powinien, co powoduje, że indeks jest 8 razy większy niż powinien, więc nie może już zmieścić się w pamięci. Ten sposób myślenia nie działa, gdy programujesz w oparciu o ogólny interfejs API, który nadmiarowo aktualizuje wszystkie kolumny w tabeli (nie, dziękuję za komponenty Java).

Nie wiedzą, co to jest pełny skan tabeli. Nie wiedzą, jak przetwarzać dane w ramach jednej operacji zamiast otwierania kursora. Gorzej niż kursor, będą wyszukiwać dane, a następnie przetwarzać je wiersz po wierszu w bazie danych, gdy wystarczy pojedyncza prosta aktualizacja. Rezultatem jest OGROMNA wydajność.

Nie znają poważnego wpływu raportowania na duże tabele. Być może potrzeba raportów będzie wymagała utworzenia schematu gwiazdy i wprowadzenia do niego danych. Twój przeciętny programista będzie po prostu sprawdzał istniejące tabele i zastanawiał się, dlaczego uruchomienie zapytania zajmuje 3 godziny (jest to prawdziwa liczba).

Wiedza przeciętnego programisty wystarcza na „przeciętne” aplikacje CRUD, w których użytkownik po prostu edytuje rekord. Nie wystarczy, gdy wyjdą z bańki Ruby-on-Crack i wkroczą do prawdziwego świata.

Zależy od tego, jak duża jest baza danych i czy jest ona współużytkowana przez wiele aplikacji. Często zespół DBA lubi wiedzieć, jakie zapytania będą uruchamiane, aby upewnić się, że istnieją odpowiednie indeksy, lub też wiedzieć, kto powiadomi, jeśli będzie musiał podzielić tabelę. I zazwyczaj są nieco lepsi niż przeciętny programista w czytaniu planów wykonania zapytań i wykrywaniu miejsc, w których można by podpowiedzieć w celu poprawy wydajności. Jest to również szansa, aby uzyskać heads-up, że w następnym wydaniu pojawią się zapytania o dużym wpływie, aby mogli zbierać różne statystyki dotyczące optymalizatora.

Nie pracowałem w takim środowisku, ja też nie.

Istnieje różnica między pracą zespołową a wrogą biurokracją. Jako programista chciałbym mieć dane DBA dotyczące trudnych zapytań. Ale wiem, kiedy poprosić o pomoc.

Jeśli nie jestem wystarczająco kompetentny do prostych SELECTzapytań, powinienem zostać zwolniony.

Widziałem to w kilku różnych miejscach. Jest świetny w teorii, ale rzadko widziałem, żeby był skuteczny. Dlatego. Po pierwsze, jeśli masz zespół DBA (lub innych osób), ogólnie stwierdziłem, że najsłabiej kompetentna lub najmniej lubiana osoba z grupy ponosi ciężar pracy związanej z recenzowaniem. Dlaczego mówisz? Jest tak, ponieważ nikt inny nie chce tego robić, a wszyscy inni są zajęci robieniem innych rzeczy, które prawdopodobnie są bardziej pilne. Widziałem kiedyś DBA siedzącego i mówiącego: „Człowieku, wszystko działa idealnie; mogę po prostu usiąść i surfować po sieci. Chciałbym mieć coś do zrobienia”. Ja też, przynajmniej nie ci dobrzy. Są tak zajęci lub zajęci jak wszyscy inni. Oznacza to, że osoba, która jest najmniej zdolna, najprawdopodobniej dokonuje przeglądu, a dokładnie takiej osoby nie chcesz robić. Kod, który chcesz sprawdzić, to naprawdę twardy kod, na który ludzie patrzą i przekazują go jako coś w rodzaju czarnej magii. Junior DBA lub po prostu złe, nigdy nie będzie w stanie uchwycić subtelności tego, jak działa naprawdę trudne zapytanie. Rzadko, jak nigdy, nikt nigdy nie mówi: „Człowieku, nie pomyślałem o wybraniu jednego wiersza ze stołu za pomocą klucza podstawowego! Dzięki DBA jesteś ratownikiem”. Więc w tym scenariuszu naprawdę wszystko, co robisz, to tworzenie dużej ilości pracy za niewielką wartość. Pomyśl o wybraniu jednego wiersza ze tabeli za pomocą klucza podstawowego! Dzięki DBA jesteś ratownikiem. ”W tym scenariuszu naprawdę wszystko, co robisz, to tworzenie dużej ilości pracy za niewielką wartość. Pomyśl o wybraniu jednego wiersza ze tabeli za pomocą klucza podstawowego! Dzięki DBA jesteś ratownikiem. ”W tym scenariuszu naprawdę wszystko, co robisz, to tworzenie dużej ilości pracy za niewielką wartość.

Po drugie, jest to po prostu więcej pracy dla grupy DB. To, co prawdopodobnie się wydarzy, nawet jeśli spojrzą na inne rzeczy, to rzucić na to okiem i coś zostanie pominięte. Są zajęci, a przeglądanie kodu zajmuje dużo czasu. W rzeczywistości to niesprawiedliwe, że mają do tego zadanie, ponieważ jest to wymówka dla wszystkich innych, aby być leniwymi i używać ich jako wyjścia, co ostatecznie się dzieje. Coś się psuje w produkcji, a programista szybko zauważa: „Dobrze, że DBA to sprawdził”. Teraz jest to prawda przez cały czas, nie, ale jest to prawdziwa część czasu i często od ludzi, którzy muszą naprawdę zweryfikować swój kod. Więc zakopałeś DBA dodatkową pracą i zmusiłeś tę osobę do odpowiedzialności za czyjeś błędy, kiedy ta osoba prawdopodobnie nie

Jedynym sposobem, aby naprawdę rozwiązać problem, jest napisanie go przez ludzi, którzy wiedzą, jak napisać kod SQL. Czy powinni od czasu do czasu uzyskiwać dane od DBA? Oczywiście powinny, ale zawsze znajdowałem, jeśli nie masz czasu, aby zrobić to dobrze za pierwszym razem, kiedy znajdziesz czas, aby to naprawić.

Pracowałem w tego rodzaju środowisku. Wszystkie zmiany systemowe zostały sprawdzone przez odpowiednich partnerów. Dla mnie oznaczało to po prostu, że musiałem planować z wyprzedzeniem i przesyłać zmiany z kilkudniowym wyprzedzeniem. SQL trafił do DBA, którzy ostatecznie wydali SQL na produkcję.

Mój SQL jest zwykle w porządku, wyłapali kilka głupich błędów. Na początku wydaje się to zbyt biurokratyczne, ale pracuję w finansach. Widziałeś, co się dzieje (jeśli jesteś w Wielkiej Brytanii) kilka miesięcy temu, gdy duży bank tutaj pomieszał rutynową aktualizację i pomieszał wszystkie transakcje prowadzące do milionów (przynajmniej setek tysięcy) osób, które nie są w stanie uzyskać za swoje pieniądze.

Poszedłbym nawet dalej. Sprawdzę otaczający kod i zobaczę, jak zmienne są przekazywane do zapytania. Często widać, jak programiści narażają swoją aplikację na ataki typu sql injection z powodu braku podstawowej wiedzy (fałszywe założenia „nie da się zhakować”).

Również niedoświadczeni programiści mogą przeciągnąć bazę danych na kolana z powodu niewłaściwego użycia ORM lub zapytania dalekiego od optymalnego.

W najnowszym projekcie, nad którym pracuję, żaden programista front-end nie ma dostępu do bazy danych bezpośrednio. Podnoszą zapotrzebowanie na funkcję zwracającą dany zestaw danych, a programiści zaplecza przygotowują go dla nich. Działa całkiem dobrze, front-end devs zapisuje interfejs użytkownika i przetwarza dane dostarczane przez funkcje napisane przez back-end devs.

W naszym zespole programistycznym jest podgrupa 4 programistów baz danych doświadczonych w używanej przez nas platformie DBMS. Piszą wszystkie SQL lub przynajmniej recenzje i dokonują zmian w celu spełnienia standardów kodowania dowolnego SQL napisanego przez deweloperów .Net. Są częścią zespołu projektowego. Produkcyjne DBA należą do zupełnie innego działu, a ich praca jest sprawna. Nie przeglądają naszego kodu SQL ani schematu, a nawet wdrożenie jest wykonywane w skryptach, wystarczy uruchomić skrypt. Najbardziej pomagają w dostrajaniu wydajności.