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

11

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.

Isvara
źródło
2
Cóż, nie umieszczamy instrukcji SQL w kodzie. Jednak WSZYSTKIE kody powinny zostać przejrzane przez odpowiednie kompetentne osoby.
CaffGeek
4
Tworzenie stron internetowych ma kluczowe znaczenie. Rezultat jest bezpośrednio skierowany do klienta (który jest twoim królem), a szczególnie wrażliwe dane są dostępne dla serwera WWW.
thiton
2
Pytanie brzmi: jeśli nie każde zapytanie jest przekazywane przez DBA, w jaki sposób określasz, co powinno i nie powinno być przekazywane przez DBA?
programista
6
@thiton: Jest to ogólne oświadczenie zakładające, że WSZYSTKIE aplikacje internetowe są skierowane do klientów publicznych i są najważniejszymi aplikacjami w organizacji. To po prostu nieprawda. Czasami aplikacje internetowe są trzeciego poziomu lub niższe (w porównaniu do innych aplikacji). Niektóre są używane tylko przez małe, wewnętrzne zespoły. Nie wiedząc, nad czym pracuje @ DanEllis, tak naprawdę nie wiemy, jak ważne jest to tworzenie stron internetowych.
FrustratedWithFormsDesigner
2
Nie zostałeś jeszcze ugryziony? Zastanów się, czy nie zapytać, dlaczego ta procedura została

Odpowiedzi:

15

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.

bwalk2895
źródło
-1 Świetna odpowiedź, ale niestety pytanie dotyczyło recenzji dba po recenzji innego programisty. Ta odpowiedź naprawdę dotyczy pytania „czy należy sprawdzić cały kod”, ale nie było to pytanie zadane. Nie głosuję za bardzo ani z niezadowolenia, tylko wtedy, gdy odpowiedzi nie są odpowiedzią na pytanie.
Michael Durrant
Dokładnie. Jest to kod, który został już sprawdzony w kontekście . To jest ważne. Pojedyncze zapytanie może wyglądać nieszkodliwie, ale umieść je w pętli, a nagle mniej.
Isvara,
1
Czy są jakieś narzędzia do automatyzacji tego rodzaju rzeczy? Mam na myśli narzędzie, które tworzy plan wykonania dla wszystkich przesłanych zapytań, a następnie oznacza wszystko za pomocą pełnego skanowania tabeli lub produktu kartezjańskiego. Wątpię, by mógł to wszystko uchwycić , ale prawdopodobnie przyspieszyłoby to czas recenzji i może być również uruchomione przez programistów za pomocą skryptu, a nawet lepiej, gdyby uruchomiło się automatycznie podczas odprawy kodu.
FrustratedWithFormsDesigner
10

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.

Michael Durrant
źródło
5

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.

BZink
źródło
6
Są to doskonałe rzeczy do zmierzenia. Ile czasu spędzasz na naprawianiu uszkodzonego kodu, który został dopuszczony do produkcji? Ile godzin zajmuje Sprzedaż i Marketing, aby znaleźć klientów, którzy zastąpią tych utraconych klientów, gdy Twoja witryna była niefunkcjonalna, ponieważ pominięta klauzula WHERE spowodowała wielokrotne skanowanie tabeli? Przegląd kodu ma koszty i korzyści, nie zaniedbuj też.
4
Dlatego ważne jest, aby wiedzieć, ile razy DBA żąda / potrzebuje zmian. Pytanie wyraźnie mówi, że wszystko jest sprawdzane, bez wyjątków. Jest to rodzaj ogólnej polityki, która zwykle wiąże się z większymi kosztami niż korzyściami. Jestem wielkim zwolennikiem przeglądu i testowania kodu, ale to nie znaczy, że każda linia jest sprawdzana lub testowana. Mamy być profesjonalistami i istnieje różnica między kontrolą jakości a siedzeniem dziecka.
BZink,
4

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.

FormerIgnorantDeveloper
źródło
Czy chciałbyś brzmieć bardziej święto niż ty?
sevenseacat
2
@Karpie, przynajmniej poświęcił czas na odpowiedź, czerpiąc z własnego doświadczenia, zamiast robić bezwartościowy, sarkastyczny komentarz do odpowiedzi kogoś innego, jak zrobił to Karpie.
Drew
2

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.

TMN
źródło
2

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.

Nathan Long
źródło
1
Chociaż jest to rozsądny punkt widzenia, musisz pozwolić, abyśmy byli bardzo nieliczni z nas tak sprytni, jak chcielibyśmy sądzić, że jesteśmy, a najgorsze przestępcy są najbardziej ignorantami (prawie z definicji nie tymi tutaj), więc unikaj tego problem polega na tym, że obowiązuje zasada kocowa - wszyscy traktują jednakowo
Murph,
2
@Murph - absolutnie. Mogę się pomylić. Ale mogłem również codziennie robić 2-godzinne przerwy w łazience. Czy wszyscy powinni śledzić czas w łazience, aby temu zapobiec? Czy powinniśmy podpisywać formularze, aby otrzymać spinacze, aby uniknąć kradzieży spinacza? W pewnym momencie musisz albo zaufać ludziom, albo zwolnić ich. Moje wolne zapytanie ma swój koszt, ale wiąże się z nim również pochłaniający dusze i czasochłonny proces przeglądu. Tylko jeśli małe różnice w wydajności bazy danych kosztowałyby miliony (lub życia), zaakceptowałbym tego rodzaju rzeczy.
Nathan Long,
1
Problem polega na tym, że prawdopodobnie nie jesteś przeciętnym programistą; i najprawdopodobniej nie problem programisty. Pracowałem w takim miejscu i to było trochę pechowe; ale wiesz co? Nasze DBA były tymi, które otrzymały telefon w środku nocy, kiedy zapytania się załamały, nie ja. Jeśli to oni ponoszą odpowiedzialność, mają prawo przejrzeć kod, za który są odpowiedzialni.
Telastyn
@Telastyn - „nie przeciętny programista”, którego nie kupuję; Nadal twierdzę, że nie zatrudniaj złych programistów. Ale tak, jeśli DBA będą musieli odebrać telefon, trochę więcej współczuję.
Nathan Long,
@Nathan Długo mówi o kontekście - w kontekście, w którym pracujesz, prawdopodobnie nie jest to problem, w innych wyraźnie widać, że ma potencjał, a jednym ze sposobów uniknięcia pewnych problemów jest posiadanie czegoś, co może wydawać się bezmyślnymi regułami (choć , jak na przykład fakt, że zawsze używam {} w moich instrukcjach if, jest to zrobione w określonym celu). Jest źle „ponieważ mi się nie podoba i myślę, że jestem bezpieczny, więc nie powinien mieć zastosowania do mnie” to wątpliwy argument (ta sama logika dotyczy ignorowania ograniczeń prędkości). Hmm, to sprzeczka) - Przepraszam.
Murph
2

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ć.

kemiller2002
źródło
2

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.

Ian
źródło
0

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.

Andrzej Bobak
źródło
0

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.

softveda
źródło