Jak DBA mogą być bardziej „przyjazne dla programistów”?

46

Odpowiedzi i komentarze dotyczące wersji dba.se i programmers.se pytania „Jakie są argumenty przeciwko lub za umieszczeniem logiki aplikacji w warstwie bazy danych?” bardzo ujawniają różnice między DBA a programistami w niektórych miejscach pracy.

Co mogą zrobić DBA inaczej, aby lepiej współpracować z programistami w takich sprawach?

Powinniśmy:

  • Studiujesz narzędzia i języki, z których korzystają nasi programiści, aby zrozumieć swoje trudności, z którymi się borykają, szczególnie podczas pracy z dobrze zaprojektowanymi bazami danych?
  • Czy zachęcić programistów do lepszego informowania o bazach danych i zaletach logiki biznesowej na poziomie bazy danych?
  • Zmienić sposób, w jaki definiujemy interfejsy do naszych danych - na przykład poprzez użycie bardziej przyjaznych dla programistów interfejsów transakcyjnych API (np. W przypadku problemów takich jak kompatybilność wsteczna)?
Jack Douglas
źródło

Odpowiedzi:

27

Z punktu widzenia programisty powiedziałbym, że najbardziej zależy nam na spójnych, dobrze zdefiniowanych i wdrożonych standardach projektowania i budowania warstwy danych. Jestem gotów grać tak, jak chcesz w swojej piaskownicy, musisz tylko powiedzieć mi, czego chcesz, i nie zmieniać zasad przez cały czas. Powinien zostać wdrożony tak samo dla wszystkich, nawet superprogrammergod. Jeśli robisz dla niego wyjątki, to chcesz, żebym je wspierał i zmieniał, ale ponownie wdrożyłem w odpowiedni sposób, który nie działa dla mnie.

I proszę, nie mów mi, żebym nie robił tego w ten sposób i odszedł. Pracuj ze mną, aby pokazać mi, czego chcesz i dlaczego twoja droga jest lepsza. Jeśli rozumiem, będę się za każdym razem stosować. Kiedy go nie rozumiem, trudniej jest go zastosować. Nie chcę być DBA. Uwielbiam programować. Nie chcę twojej pracy, a jeśli jesteś dobrym DBA, będę twoim największym fanem.

Czad
źródło
63

Byłem MySQL DBA przez ostatnie 6,5 roku. Spędziłem również około 16 lat jako programista i współpracowałem z wieloma DBA. Wiele z nich jest pragmatycznych. Niektóre z nich są wstrętne. Niektórzy nie mają pojęcia, co to znaczy być DBA.

Doszedłem do tego wniosku:

Technicznie rzecz biorąc, najlepiej jest pracować z DBA, które mają jedną lub więcej z następujących cech:

  1. Spędziłem lata jako sami programiści
  2. Zapoznaj się z teorią baz danych
  3. Dobrze zrozum, jak RDBMS działa wewnętrznie
  4. Posiadaj doskonałą wiedzę na temat systemu operacyjnego

Bardzo zdyscyplinowane, kompetentne DBA mają wiele do zaoferowania. Mogą zobaczyć wydajność bazy danych z perspektywy, która nie jest tak naprawdę rozważana przez programistów. Programiści wiedzą, czego chcą od bazy danych. DBA wiedzą, jak być „uprzejmym” wobec bazy danych.

Jeśli chodzi o osobowości, zawsze będą konflikty, małostkowość, a może nawet zazdrość. Jedno jest pewne: DBA i Deweloperzy nie są w żadnej szczególnej kolejności jak mężowie i żony (jestem szczęśliwym małżeństwem od 16 lat z trwającymi projektami [4 dzieci]).

Niezależnie od tego, kto jest postrzegany jako mąż, a kto jako żona, obowiązują te zasady:

  1. jeden musi skonsultować się z drugim
  2. jedna musi cenić perspektywę drugiej
  3. należy podejmować decyzje dla dobra obu stron
  4. należy popierać, a nie sabatoge, podjętą decyzję
  5. nie wolno oczerniać drugiego, jeżeli decyzje prowadzą do złych konsekwencji
  6. należy cieszyć się z wkładu obu stron w powodzenie decyzji
  7. należy skonsultować się z wyższym organem (HA), jeśli decyzja nie może być wzajemnie uzgodniona

Te siedem (7) zasad stosuje się w równym stopniu w miejscu pracy, szczególnie w dziedzinie IT.

Komunikując się na każdym etapie, wszyscy powinni:

  1. układ ich oczekiwania
  2. budzą szacunek dla zdolności drugiej strony do wykonania swojej części na podstawie wcześniejszych wyników
  3. mieć zaufanie i pewność, że druga strona może wykonać swoje zadanie
  4. spełnić nasze własne oczekiwania
  5. przyswajać pod kierunkiem HA (patrz zasada nr 7)

Nie ma w tym miejsca na mikrozarządzanie. DBA NIE POWINNI POWIEDZIEĆ Programiści, jak myśleć jak DBA. Deweloperzy NIE POWINNI POWIEDZIEĆ DBA, jak być programistami. Ostateczne decyzje dotyczące wydajności i użytkowania bazy danych muszą spoczywać na DBA . Ostateczne decyzje dotyczące potrzeb aplikacji muszą leżeć w gestii programistów . Tę symbiozę należy zawsze utrzymywać.

KOŃCOWE PRZEMYŚLENIA

Zasada nr 7 wymaga aktywnego udziału i nadzoru WYŻSZYCH ORGANÓW (HA), tj. Kierownika projektu, lidera zespołu, głównego programisty. Twój HA lepiej wie, jak obie strony pracują indywidualnie i jak obie strony powinny ze sobą współpracować. Jeśli HA nie ustanowi podstawowych zasad dla obu stron lub HA nie będzie kierować stronami indywidualnie i wspólnie, projekty zawsze w pewnym momencie się zatrzymają i zagrażają samemu istnieniu (zatrudnieniu) Dewelopera, DBA, a nawet HA.

RolandoMySQLDBA
źródło
28

Posiadanie zespołów w różnych sekcjach / piętrach w jakiś sposób wydaje się zachęcać do mentalności „my kontra oni”.

Siedzenie DBA pośrodku zespołu programistów to świetny sposób na zburzenie ściany programisty / DBA. Zarówno DBA, jak i programiści skorzystają na tym, jeśli pozostaną otwarci i odłożą swoje ego na bok.

Komunikacja osobista, szczególnie przy dzieleniu się pomysłami, jest znacznie bardziej skuteczna niż poczta elektroniczna i ma mniejsze szanse na wywoływanie uczuć z powodu nieporozumień.

datagod
źródło
20

Tego rodzaju rzeczy różnią się znacznie w zależności od miejsca. W mojej obecnej witrynie granica między programistami a DBA jest rzeczywiście bardzo rozmyta - my (DBA) również piszemy PL / SQL, a oni (programiści) analizują plany zapytań. Wszyscy postrzegamy siebie jako rówieśników, jedynie z różnymi umiejętnościami i obowiązkami. To bardzo zabawne: ostatnio firma włączyła się w modę DevOps . Społeczność baz danych w ogóle tego nie rozumie; my zawsze pracował tak. Nie trzeba dodawać, że pracujemy tak niezwykle wydajnie: poziom bazy danych jest zdecydowanienajbardziej niezawodna część stosu technologicznego firmy, jest łatwa w obsłudze (ponieważ mamy umiejętności w zespole DBA, aby zrozumieć aplikację na głębokim poziomie, a programiści mają dostęp do DBA, aby zrozumieć operacje 24/7/365 i jak ustrukturyzować w tym celu swoje aplikacje).

Ale wiem, co masz na myśli, mówiąc o „złym” rodzaju programisty. Jest samoukiem, co samo w sobie jest szlachetną rzeczą, ale po drodze nabrał nieufności do jakichkolwiek formalnych instrukcji. On nie wie, co on nie wie , a on nie znosi ktoś próbuje go oświecić, widzi go jako obraza jego umiejętności samokształcenia. Nauczył się imperatywnego stylu programowania, ponieważ możesz się go nauczyć bez żadnej teorii, o której zawsze gaworzą typy CS (no cóż, źle; każdy musi znać duże Oi podobne fragmenty teorii). Nauczył się trochę OO, tylko dlatego, że musi korzystać z Javy. Ale dobry specjalista od baz danych - programista lub DBA - musi swobodnie myśleć w stylu deklaratywnym, myśleć o teorii mnogości, normalnych formach, a nawet być w stanie zrozumieć algebrę relacyjną i rachunek różniczkowy. Bardzo trudno jest komunikować się z tymi ludźmi, ponieważ są oni aktywnie wrogo nastawieni do wszystkiego, co mogłoby ich wyrzucić ze strefy komfortu, która zasadniczo ogranicza się do sformatowania czegoś na stronie internetowej. Jeśli w ogóle myślą o bazach danych, myślą, że tabela jest jak klasa, a wiersz jest jak obiekt. Ci faceci dosłownie robią, SELECT * FROM TABLEfiltrują i sortują wyniki we własnym kodzie. Naprawdę, naprawdę nie rozumieją, dlaczego baza danych jest lepsza niż plik płaski (i nie tak potajemnie uważają, że każdy, kto korzysta z relacyjnej bazy danych, jest idiotą).

Dam ci prawdziwy przykład: ostatnio rozmawiałem z jednym z tych typów o problemach związanych z wycofaniem wersji naszego oprogramowania po jego wprowadzeniu do produkcji, jeśli problem przeszedł przez kontrolę jakości. Wyjaśniłem, że chociaż możemy wycofać jego aplikację (jedną z wielu uzyskujących dostęp do bazy danych), musiałaby być w stanie działać przy wciąż wdrożonej bazie danych. Zapytał dlaczego, a ja powiedziałem, no cóż, w tych nowych tabelach i kolumnach będą prawdziwe dane klientów. Następnie powiedział, więc po prostu skopiuj go do tymczasowego stołu, w czym jest problem. Patrzyłem na niego z niedowierzaniem: kiedy klient dzwoni i mówi, moje pieniądze zniknęły z mojego konta, co mu mówimy, że jest w porządku, to jest na tymczasowym stole? Po prostu nie zrozumiał, że kiedy masz do czynienia z pieniędzmi innych ludzi, musisz zachowywać się jak odpowiedzialny dorosły. Z tego, co wiem, nadal tego nie robi; nie ma go już u nas.

Obóz MySQL był taki przez długi czas; powiedzieliby, że nie potrzebujesz transakcji, kluczy obcych itp., jeśli myślałeś, że to zrobisz tylko dlatego, że nie miałeś pojęcia, co robisz itp. itd. (wtedy, gdy dorastali, po cichu je dodali). Są to ludzie, dla których opracowano ORM, takie jak ActiveRecord lub Hibernate, aby mogli pisać aplikacje baz danych bez konieczności dotykania SQL. Wykorzystanie tych technologii uważam za czerwoną flagę - nie jest to firma, która ceni umiejętności DBA. To, czego naprawdę chcą, to opiekunka do dziecka ...

Gajusz
źródło
18

Jako programista rozumiejący bazę danych uczynił mnie lepszym programistą. Kiedy zostałem administratorem bazy danych, stało się to jeszcze ważniejsze, dlatego uważam, że edukacja jest kluczem.

DBA powinny cierpliwie prowadzić programistów traktując ich jako kompetentnych specjalistów. Niewielu programistów, gdy zostanie pokazana różnica między operacją ustawiania a operacją rząd po rzędzie po stronie klienta, będzie dręczyć ten pomysł. Mamy te same cele - szybkość aplikacji, bezpieczeństwo danych, łatwość konserwacji itp. Dotyczy to nie tylko logiki aplikacji, ale także wszystkich aspektów interakcji z bazą danych. Programiści chcą lepiej korzystać ze swoich narzędzi, a im więcej DBA może im pokazać, jak lepiej korzystać z narzędzia bazy danych, tym więcej oboje skorzystają.

Leigh Riffel
źródło
12

Bez względu na to, jaką infrastrukturę obsługujemy, musimy wspierać jej użytkowników. Wielu użytkowników jest programistami, dlatego wspieramy programistów, aby umożliwić im jak najlepsze wykorzystanie tej infrastruktury. Aby móc to zrobić, musimy się zrozumieć, mając na uwadze różne pomysły i punkty widzenia. Wgląd w opinie obu stron pomaga poprawić sytuację firmy i jest to nasz wspólny cel. Spraw, aby wsparcie IT działało jak najskuteczniej.

W wielu organizacjach widzimy niektóre typy dba działające w trybie boga. W większości przypadków nie są to te, które osiągają bardzo dobre wyniki, jeśli mierzy się kompetencje ... Często po prostu ukrywają - brak - wiedzy za ścianą słów.

Moim zdaniem nie ma to nic wspólnego z byciem „przyjaznym programistom” bardziej z byciem profesjonalistą. W przypadku dba oznacza to, że musimy być w stanie wyjaśnić, dlaczego robimy to, co robimy, i być przygotowanym na decyzję o ponownym rozważeniu dzierżawy, jeśli to pomoże, bez utraty normalnych celów, takich jak dostępność, skalowalność, możliwość odzyskania i wydajność. Dla programisty oznacza to, że musi komunikować się z dba, czasem uczyć dba, czasem uczyć się od dba. Moje motto na ten temat brzmi: niech pierwszy dzień, kiedy niczego się nie nauczę, będzie dniem, w którym trumna zamyka się nad moją głową. Normalna współpraca, łączenie zespołów z programistami i programami dba z pewnością ułatwia pracę.

ik_zelf
źródło
9

Myślę, że częścią problemu jest perspektywa. DBAS, analitycy danych i programiści baz danych muszą z czasem radzić sobie z danymi. Twórcy aplikacji martwią się, jak sprawić, by działały, gdy wysyłają je do produkcji. Nie martwią się tak bardzo o to, jak będą wyglądać dane za sześć miesięcy, o ile nie wystąpią błędy podczas ich wdrażania.

Ale ludzie danych muszą żyć z wynikami krótkowzrocznych decyzji, które powodują utratę integralności danych lub wstawianie zduplikowanych rekordów, a następnie próbują wyjaśnić, dlaczego dane są złe. DBA są tymi, którzy muszą poradzić sobie z problemem wydajności z procesu, który działał dobrze, gdy było tylko tysiąc rekordów, ale teraz zajmuje godziny z 100 000 000 rekordów.

Bazy danych są trudniejsze do refaktoryzacji, więc DBA martwią się, czy uda się to zrobić za pierwszym razem. Deweloperzy nie widzą problemu przy refaktoryzacji w dół drogi.

Deweloperzy nie widzą problemu z tym, aby baza danych działała tak, jakby była obiektowa, ludzie bazy danych wiedzą, że nie jest to najbardziej efektywny ani wydajny sposób przechowywania lub uzyskiwania danych.

Twórcy aplikacji często zajmują się tylko niewielkim podzbiorem rekordów, ale nie importem / eksportem dużych danych ani raportowaniem. Rzeczy, które działają dobrze, aby wprowadzić jeden rekord, nie działają, gdy mówimy o imporcie miliona. Logika biznesowa w aplikacji (która często nie jest dostępna dla aplikacji raportującej) nie pomaga autorowi raportów uzyskać takie same wyniki dla miliona rekordów, jak to, co jest wyświetlane na ekranie po jednym rekordzie.

Inną częścią problemu jest brak szacunku po obu stronach. Spotkałem więcej niż kilku twórców aplikacji, którzy uważają, że praca z danymi nie jest trudna ani interesująca, i którzy wierzą, że wykonalibyście tę pracę tylko, jeśli nie moglibyście włamać się do jej świata. Ludzie nie reagują dobrze na traktowanie ich tak, jakby byli głupi i bezużyteczni. Z drugiej strony niektóre DBA traktują deweloperów aplikacji również z lekceważeniem, a ich zadania polegające na przeglądaniu tego, co robią programiści, są traktowane jako niski priorytet (co może być w przypadku dużych złożonych baz danych produkcyjnych). Mogą odmówić usłyszenia lub reagowania. Kto chce, aby cały projekt został zawieszony, dopóki DBA nie przejrzy go dwa tygodnie później? A potem mówi ci, że to niedopuszczalne i musisz przepisać całość?

HLGEM
źródło
8

Przez wiele lat, odkąd zacząłem pracę z SQL Server (1998), wielu programistów mówiło mi, jak mam wykonywać swoją pracę. To interesujące, że wszyscy wiedzą więcej ode mnie, a także są doskonałymi programistami .net. W rzeczywistości są też architektami i powinni robić coś więcej niż małpowanie kodu.

Być może to niewłaściwe podejście ode mnie: ale w wielu sklepach jest to dość powszechne podejście deweloperskie. Robią to także sobie nawzajem, pamiętajcie: patrzcie, jak zaczynają się walki, kiedy sugerujecie recenzje.

Poprawki pozostawiam innym odpowiedziom (do tej pory zgadzam się w 100% z 2), ale dodam, że zarządzanie i kultura sklepu muszą również wspierać i pielęgnować współpracę.

gbn
źródło
8

Jako programista wszystko, czego potrzebuję, to wiedzieć, jak chcesz, żebym komunikował to, czego potrzebuję. Jeśli proszę o coś śmiesznego, muszę, żebyś mi powiedział - a jeśli mi powiesz, uwierzę w to, ponieważ masz doświadczenie w uczciwości. Jeśli nie rozumiesz, o co proszę, poświęć czas, aby wyjaśnić mi, co myślisz, że mam na myśli - a ja poświęcę czas na wysłuchanie.

... Wspólny temat, prawda ... Komunikacja ... komunikacja ... komunikacja.

Naprawdę nie ma lepszego sposobu, aby to ująć. Deweloperzy są zaznaczani, ponieważ: „że DBA powiedziała mi, że nie da się tego zrobić - na pewno udowodniłem mu, że ostatnim razem się mylił”. DBA są zaznaczone, ponieważ „ten programista nie rozumie, co muszę robić za każdym razem, gdy zmienia specyfikację”.

Deweloperzy i DBA, jak stwierdził @Rolando, muszą się rozumieć. Kiedy wszystko sprowadza się do tego, oboje mówimy „Ones & Zeros” - można by pomyśleć, że byłoby to dobre dopasowanie. Mamy 2 dziedziny odpowiedzialności: DBA mają dane, a programiści zajmują się resztą komputera. Ale bez danych programiści naprawdę nie mieliby wiele do roboty.

Nie mamy DBA i czasami jest to bolesne. Ta część mnie, która dziesięć lat temu chciała być DBA, skurczy się, gdy zobaczę niektóre rzeczy, które robimy. Gdybyśmy jutro wynajęli DBA, myślę, że pocałowałbym ziemię, po której szedł.

IAbstract
źródło
7

W niektórych firmach, być może wielu, opracowywanie produktów ma tendencję do ignorowania każdego, kto nie pisze w skompilowanym języku. Gdy nadejdzie czas wydania, pojawia się opór, ponieważ każdy z administratorów sieci, administratorów systemów, administratorów systemów, wsparcia użytkowników itd. Musi przeprowadzić należytą staranność. Często występują bóle głowy, ponieważ nie uwzględniono kluczowych aspektów środowiska. To naturalnie powoduje napięcia między zespołami.

Kto jest tutaj winien? Pani komunikacji.

Programiści muszą zrozumieć kod środowiska, w którym zostaną wdrożone. Ludzie muszą otrzymać odpowiednie ostrzeżenie w celu dostosowania. Tam, gdzie środowisko nie może się przystosować z jakiegokolwiek powodu (bezpieczeństwo, sprzęt, zasady), oprogramowanie musi się dostosować. Jeśli tak się stanie podczas procesu projektowania i wdrażania, wszyscy są zadowoleni. Jeśli nie rozpocznie się przed czasem wdrożenia, będzie to świat cierpienia.

Tak, zespoły muszą ze sobą rozmawiać (i słuchać), ale kierownik projektu / produktu musi stworzyć środowisko, w którym może się to zdarzyć.

Miałem szczęście, w większości miejsc, w których pracowałem, wzajemny szacunek i komunikacja są częścią kultury.

Phil Lello
źródło
6

Jedną rzeczą, którą dobry DBA musi zrozumieć, jest polityka danych. Przez kilka lat uczyłem programowania i projektowania baz danych doświadczonym programistom i kilku opracowanym DBA. Jedno z pytań, które pojawiało się regularnie, brzmiało: dlaczego wszystkie bazy danych w moim sklepie są tak polityczne?

Oto moja standardowa odpowiedź: jeśli baza danych jest przydatna, to udostępniasz dane. Jeśli dzielisz dane, to dzielisz moc. Kiedy władza jest dzielona, ​​dzieje się polityka.

Nie ma znaczenia, czy kochasz politykę, czy nienawidzisz polityki. Jeśli masz zamiar wykonać dobrą pracę z bazą danych, przyzwyczaj się do tego.

Nawiasem mówiąc, niektórzy z was pracowali tylko w środowisku programistycznym. Istnieją DBA, którzy pracują po stronie produkcyjnej ogrodzenia i mają niewielką interakcję z programistami. Możesz myśleć, że w produkcji jest mniej polityki. Jest więcej. Duże produkcyjne bazy danych są zwykle przeznaczone dla całego przedsiębiorstwa i mają kluczowe znaczenie.

Walter Mitty
źródło
3

Trochę pokory może pomóc niektórym z was. ;)

Istnieją oczywiście uzasadnione argumenty dla obu podejść, sugeruję zacząć od rozpoznania tego. Rozwój oprogramowania polega na podejmowaniu właściwych kompromisów. Jeśli jest to ulica dwukierunkowa, być może DBA również powinny zachować otwarty umysł.

eevar
źródło