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