Czy doświadczeni programiści powinni znać zapytania do bazy danych? [Zamknięte]

35

Jest tak wielu programistów, którzy są również ekspertami w pisaniu zapytań i projektowaniu baz danych.

Czy powinien to być podstawowy wymóg bycia ekspertem programistą lub inżynierem oprogramowania?

Chociaż istnieje wiele podobieństw w sposobie opracowywania zapytań i kodów, moja osobista opinia jest taka, że zapytania wydają się mieć inną Strukturę niż Kod i trudne może być opanowanie obu jednocześnie ze względu na różne podejścia.

database query

— Shamim Hafiz
źródło

2

Co rozumiesz przez „strukturę”? Jeśli mówisz o semantyce, to uchwycenie jakiejkolwiek nowej semantyki nie powinno stanowić problemu dla „ eksperta ”. Zgodnie z definicją. OTOH, tylko nieliczni programiści są narażeni na bazy danych i języki zapytań, reszta z nas wcale to nie obchodzi.

— SK-logic

3

Myślę, że jest to błędne założenie: „Jest tak wielu programistów, którzy są również ekspertami w pisaniu zapytań i projektowaniu baz danych”. Jest stosunkowo niewielu programistów, którzy są ekspertami w tych sprawach: DBA! = SE.

— Ashley,

1

Jak trudno jest pisać zapytania do bazy danych?

— Captain Sensible

@CaptainShakespeare, naprawdę może stać się dość trudny, gdy minie się operacje CRUD. Ty czasami robi złożone raporty. A następnie spójrz na zapytania dotyczące dostrajania wydajności.

— HLGEM,

69

To, czy pisanie zapytań do bazy danych powinno być podstawowym wymogiem, zależy od zadania, ale relacyjne bazy danych są wszechobecne w obecnej technologii.

Gdybym więc spotkał programistę, który nie wiedziałby, jak pisać zapytania do bazy danych, oczekiwałbym jednej z dwóch rzeczy:

Są na ogół niedoświadczeni.
Są wysoce wyspecjalizowani w innej dziedzinie (np. Systemy wbudowane) i nigdy nie musieli się uczyć.

Zapytania do baz danych różnią się zasadniczo od bardziej standardowych języków programowania. Są algebraiczne i przeznaczone do działania na relacyjnych danych, podczas gdy C # lub Java są niezbędne i działają na dyskach, pamięci, danych wejściowych użytkownika itp. Nawet funkcjonalne języki, takie jak LISP lub Haskell, które są bardziej algebraiczne w formie, są mniej zorientowane na dane relacyjne.

EDYCJA: Jak wskazano w komentarzach moich i innych, istnieje kilka ważnych powodów, dla których doświadczony programista może nie znać dobrze zapytań do bazy danych:

Ich zespół użył ORM / NoSQL
Ich zespół miał programistów DB
Złożoność aplikacji polegała na logice biznesowej, a zapytania DB były trywialne
Ich zespół podzielił pracę tak, że niektórzy programiści nie pisali zapytań

Chociaż są to ważne, te zastrzeżenia nie są przekonującymi powodami, dla których doświadczony programista nie znałby zapytań do bazy danych. O ile nie jest wysoce wyspecjalizowany, programista powinien znać relacyjne bazy danych.

Podsumowując, najbardziej doświadczeni programiści powinni znać zapytania do bazy danych .

— Matthew Rodatus
źródło

1

Jeśli więc ktoś wykonał nietrywialny projekt wykorzystujący bazę danych, oczekuje się, że zapozna się z zapytaniami, prawda?

— Shamim Hafiz

3

@Shamim, spodziewałbym się, że ta osoba będzie miała umiarkowane doświadczenie w zakresie zapytań, chyba że ta osoba była na poziomie niższym lub młodszym. Być może ta osoba ma tylko kilka lat doświadczenia i była chroniona w wysoce wyspecjalizowanym zespole?

— wałek klonowy

12

@Shamim prawdopodobnie bym się tego spodziewał. Nadal mogą być dobrym programistą. Na takie pytania trudno jest odpowiedzieć, ponieważ jest tak wiele zastrzeżeń: może zespół miał programistę DB; być może nietrywialność aplikacji wynikała z logiki biznesowej, a zapytania do bazy danych były trywialne; może podzielili pracę tak, że twój programista nie działał przy zapytaniach; itp.

— Matthew Rodatus

4

Mój zespół programistów zaangażował programistów PL / SQL w ramach projektu. Tak więc, chociaż programiści .Net mogą wykonywać proste zapytania, są w stanie je przejrzeć i opracować bardziej złożone zapytania. Co więcej, w związku z rozprzestrzenianiem się ORM (i NOSQL), dlaczego uważasz, że programiści spoza SQL muszą znać złożone zapytania.

— softveda

2

@Matthew Rodatus: Pracowałem w miejscach, w których były biblioteki, które zarządzały zapytaniami, więc teoretycznie można by tam pracować bez zrozumienia prostego SQL. Wierzę, że wszyscy programiści byli w tym kompetentni w praktyce.

— David Thornley,

23

Każdy inżynier oprogramowania powinien posiadać podstawową wiedzę o bazach danych oraz o tym, jak przechowywać i pobierać dane za pomocą SQL, przynajmniej do poziomu, w którym rozumieją, do czego można to wykorzystać (a wraz z tym obejmowałbym rozumienie kluczy, widoków , procedury składowane i wyzwalacze).

Nie każdy inżynier oprogramowania musi być ekspertem, a wymagany poziom wiedzy naprawdę zależy od rodzaju oprogramowania, na którym się koncentruje. Oprogramowanie wbudowane, sterowniki sprzętowe i systemy operacyjne rzadko korzystają z SQL, ale aplikacje (bazujące na sieci Web, komputerze lub usłudze / demonie) cały czas korzystają z baz danych.

— wolfgangsz
źródło

1

Na szczęście w dzisiejszych czasach robienie aplikacji bez RDBMS jest całkowicie w porządku. Większość zadań ich nie potrzebuje lub po prostu nie można ich odpowiednio zmapować na model relacyjny. Dostępnych jest wiele nierelacyjnych opcji przechowywania.

— SK-logic

8

To także podsumowuje moją opinię. Ekspert? Brak wiedzy? Tak.

— Wayne Molina

2

@ SK-logic, jakie rodzaje opcji sprawiają, że relacyjne bazy danych są nieistotne? Datawarehousing jest zbyt wyspecjalizowany, aby analityka była użyteczna w systemie transakcyjnym. I nie każ mi zaczynać od wszystkiego, co jest nie tak z OODBMS.

— wałek klonowy

1

@maple_shaft, istnieje wiele specjalistycznych, zorientowanych na domeny rozwiązań pamięci masowej. RDBMSes stara się być ogólny i nie udaje mu się to. W niektórych przypadkach nawet starożytne hierachiczne DBMS są znacznie lepsze niż relacyjne.

— SK-logic

6

Nie wszystkie programy komputerowe używają baz danych, więc zachowaj ostrożność, gdy mówisz, że dzieje się to cały czas.

— Adam Lear

18

Istnieją pewne obszary specjalizacji (na przykład systemy wbudowane), w których wiedza na temat baz danych nie jest potrzebna. Ale większość aplikacji biznesowych korzysta z pewnego rodzaju bazy danych, a jeśli nie rozumiesz, jak właściwie z niej korzystać, możesz stworzyć bałagan wydajności, który jest niezwykle trudny do naprawienia. Refaktoryzacja baz danych może być złożonym i trudnym procesem, a wiele miejsc decyduje się nie naprawiać problemów strukturalnych z powodu tej trudności i po prostu kopać się głębiej w dziurę. Jeśli masz wiedzę na temat baz danych, projektowanie jest znacznie łatwiejsze i znacznie bardziej prawdopodobne, że z czasem będzie dobrze działać.

ORM nie zastępują wiedzy na temat bazy danych. Każdy, kto korzysta z niego, nie znając podstaw zapytań i projektowania baz danych, jest skazany na słabo działającą, źle zaprojektowaną bazę danych, która wpłynie na zdolność aplikacji do obsługi dużego obciążenia. ORM w rękach kogoś, kto wie, co robi, jest w porządku; w rękach ludzi, którym nie przeszkadzają informacje o bazach danych, zwykle są katastrofą.

Gdybym miał projekt z zapleczem bazy danych, specjalista ds. Baz danych byłby drugim programistą, którego zatrudniłbym (po programistach aplikacji wstępnych). Bazy danych na ogół nie są rzucane, że dane będą nadal w takiej samej formie 20 lat później, opłaca się mieć wiedzę na początkowych etapach.

Projekty często mają problemy, ponieważ nie zatrudniają tych ludzi, dopóki baza danych nie ma 100 000 000 rekordów i nie działa wolno. Lub obwiniają narzędzie za złe (żaden SQL Server nie jest powolny, jeśli poprawnie projektujesz), a nie za niekompetencję projektową.

— HLGEM
źródło

4

+1 za wzmiankę, że obecność ORM nie zastępuje potrzeby znajomości SQL (lub podstawowych czynników w każdym typie db, którego używasz).

— RHSeeger

4

+1 i chciałbym dać ci 100 więcej! Znam tę korelację! = Związek przyczynowy, ale dla mnie bardziej niż oczywiste jest, że najskuteczniejsi twórcy aplikacji, z którymi kiedykolwiek pracowałem, doskonale rozumieli, jak napisać standardowe zapytanie SELECT. Powinienem być w stanie przekazać dobry programista model danych i „pytanie” na temat danych, a ta osoba powinna w końcu móc napisać zapytanie, które „odpowiada” na moje pytanie.

— wałek klonowy

1

+1, całkowicie się zgadzam. Nie kupuję wyjaśnienia, że „używamy ORM” lub „mamy do tego dedykowanych programistów”. Jeśli ktoś jest naprawdę doświadczony , w pewnym momencie pełniłby rolę programisty db. Takie jest doświadczenie.

— GrandmasterB,

15

Politycznie poprawna odpowiedź: to zależy. Znajomość SQL nie ma żadnej wartości, jeśli programista nigdy nie pracuje z relacyjnymi bazami danych (w dzisiejszych czasach aplikacji NoSQL jest to całkiem prawdopodobne).

Po drugie, gdy istnieje DBA lub pełnoetatowy pisarz zapytań (bez względu na tytuł), zrozumienie ma również mniejsze znaczenie.

Jest to naprawdę ważne tylko wtedy, gdy deweloper musi być profesjonalistą i jego projekty wymagają użycia relacyjnej bazy danych (na przykład w staroświeckich aplikacjach internetowych lub łączeniu się z istniejącymi bazami danych).

Moja osobista opinia: Nie. Doświadczony programista powinien być w stanie nauczyć się nowych umiejętności (takich jak SQL), jeśli i kiedy zajdzie taka potrzeba, a nie „domyślnie”. Elastyczność i umiejętność uczenia się i rozumienia to, imho, to, co odróżnia dobrego programistę od dobrego. Obowiązuje również zasada „złotego młota” - jeśli masz programistę z rozległą znajomością SQL, jest bardzo prawdopodobne, że ten program wyciągnie narzędzie, które zna najlepiej - relacyjne bazy danych - aby spróbować rozwiązać każdy problem, choć niekoniecznie być najlepszym rozwiązaniem. Oczywiście dotyczy to również zwolenników NoSQL;).

Doświadczony programista powinien wybrać odpowiednie narzędzie do odpowiedniej pracy.

— Cthulhu
źródło

Bazy danych NoSQL nie przetwarzają większej ilości danych lub szybciej niż relacyjne bazy danych. Nie wiem, skąd to usłyszałeś, ale to rażąco, niebezpiecznie źle.

— Aaronaught

@Aaronaught - Zredagowano, dziękuję za informacje na temat mojego przedwczesnego założenia, :).

— Cthulhu

7

Sprawdź to wikipedia wprowadzenie do programowania komputerów:

Programowanie komputerowe (często skracane do programowania lub kodowania) to proces projektowania, pisania, testowania, debugowania / rozwiązywania problemów oraz utrzymywania kodu źródłowego programów komputerowych. Ten kod źródłowy jest napisany w języku programowania. Celem programowania jest stworzenie programu, który wykazuje określone pożądane zachowanie.

Zapytania do baz danych mają swoje własne języki, można je projektować, testować, debugować i utrzymywać. Celem zapytania do bazy danych jest umożliwienie uzyskania potrzebnych informacji w sposób, w jaki są one potrzebne.

Więc myślę, że to programowanie.

— guiman
źródło

7

Dobry inżynier oprogramowania z doświadczeniem w aplikacjach korporacyjnych i biznesowych (EDIT: szczególnie w projektach wykorzystujących RDBMS) powinien posiadać specjalistyczną wiedzę na temat pisania zapytań do relacyjnych baz danych w standardowym formacie. Ponadto powinni być w stanie zrozumieć złożony schemat i zaproponować projekty schematów o co najmniej umiarkowanej złożoności.

Niezwykle zaawansowane lub skomplikowane projektowanie schematów powinno być domeną projektanta danych lub architekta funkcjonalnego.

To nie znaczy, że programiści baz danych też nie mają miejsca. Skomplikowane procedury składowane, złożone i wydajne zapytania oraz projektowanie oprogramowania i architektury warstw baz danych skoncentrowane na unikalnych narzędziach i ofertach jednego dostawcy bazy danych (np. Oracle, MySQL, SQLServer itp.) Najlepiej pozostawić profesjonalnemu oprogramowaniu, jeśli to możliwe inżynierowie, którzy mają doświadczenie w tych wysoce wyspecjalizowanych i skomplikowanych ofertach.

Zdecydowana większość systemów biznesowych i korporacyjnych moim zdaniem nie usprawiedliwia jednak potrzeby modelarzy danych i wyspecjalizowanych programistów baz danych, ale pracowałem nad takimi projektami wcześniej, że DOKŁADNIE skorzystałem z wiedzy i doświadczenia, które ci ludzie przynieśli do stołu.

— wałek klonowy
źródło

2

-1: zdecydowanie nie zgadzam się, że „dobry” inżynier oprogramowania powinien być ekspertem w zakresie zapytań dotyczących relacyjnych baz danych.

— John Saunders,

3

Czy nadal nie zgodziłbyś się, jeśli powiem, że dobry inżynier oprogramowania dla przedsiębiorstw ENTERPRISE lub BUSINESS (w przeciwieństwie do systemów wbudowanych itp.) I gdybym powiedział, że ta osoba powinna być ekspertem w zapytaniach dotyczących relacyjnych baz danych STANDARD (bez dostawcy fantazyjnych spodni) szczegóły, takie jak zapytania analityczne i tym podobne)? Dogłębne zrozumienie instrukcji SQL SELECT, wszystkich typów złączeń, związków, przecięć i scaleń, widoków wbudowanych, warunków, porządkowania i grupowania zestawów wyników powinno być dokładnie zrozumiane i szczegółowo zademonstrowane przez KAŻDEGO inżyniera oprogramowania, który nosi etykiety, które określiłem powyżej.

— wałek klonowy

4

Meh Pracuję w dużej firmie programistycznej i nie zajmujemy się żadnym RDBMS. Moja ostatnia praca polegająca na tworzeniu oprogramowania komputerowego również nie wymagała SQL. Nie jestem pewien, w jaki sposób definiujesz aplikacje korporacyjne i biznesowe, ale wydaje mi się, że twój pogląd na sprawy jest nieco wąski.

— Adam Lear

2

Trzymam się tego, co powiedziałem. Teoretycznie, jeśli aplikacja jest wielopoziomowa i dobrze skomponowana, to nie ma potrzeby w całym moim doświadczeniu zawodowym, mój zespół i zrobiłbym DROWNED, gdybyśmy nie byli ekspertami w SQL, nawet gdybyśmy mieli dedykowany zespół do projektowania i rozwoju RDBMS. Może jestem staroświecki lub po prostu mam pecha w mojej karierze?

— wałek klonowy

3

@maple_shaft Tak, to nie jest tak, że aplikacje, nad którymi pracowałem, były wystarczająco skomponowane. Po prostu nie używali RDBMS, kropka. Chyba różne dziedziny. Chodzi o to, że nie można powiedzieć, że każdy programista biznesowy musi być dobry w języku SQL. To po prostu nieprawda. Bądź w tym dobry, jeśli go używasz. Nie przejmuj się zbytnio, jeśli tego nie potrzebujesz, tak jak w przypadku każdego innego języka lub technologii.

— Adam Lear

6

Inni już odpowiedzieli na twoje pytanie dotyczące zapytań do bazy danych.

Projektowanie baz danych jest szczególnym rodzajem projektów. Nie jest to trudne do nauczenia, ale typowy projektant bazy danych nie ma tylu możliwości zaprojektowania bazy danych.

Miejsce, w którym pracuję, ma ten sam projekt bazy danych, co w 1970 roku. Przenieśliśmy bazę danych z IDMS do DB2, ale jest to ten sam projekt sieciowej bazy danych. Miałem okazję utworzyć 5 nowych tabel DB2 w ciągu 9 lat, kiedy tu pracowałem.

Podejrzewam, że jest bardzo mało miejsc pracy z dedykowanym projektantem baz danych. Doszedłem zatem do wniosku, że projektowanie baz danych jest uważane za część repertuaru starszego analityka.

— Gilbert Le Blanc
źródło

5

Jestem szczerze zdziwiony, że tak wielu z nas myśli, że każdy rozwój opiera się na bazie danych, a także na bazie SQL.

Inni wspominali o wielu sposobach unikania drobiazgowości SQL w naszych zadaniach, nawet gdy pracujemy (pośrednio) z bazami danych, ale co z wszystkimi programistami, którzy piszą oprogramowanie dla 101 produktów elektrycznych, każdy z nas posiadać? A co z facetami specjalizującymi się w monitorowaniu w czasie rzeczywistym?

Sugerowałbym, że większość dzisiejszych programistów będzie w różnym stopniu posiadała umiejętności posługiwania się językiem SQL, ale daleko im do bycia barometrem ich umiejętności.

— cjmUK
źródło

5

Myślę, że przeceniasz znaczenie baz danych w oprogramowaniu.

Wiele klas aplikacji nie jest skoncentrowanych na bazie danych.

Czy potrzebujemy teraz DBMS w edytorach tekstu i edytorach obrazów? Co z rozpoznawaniem mowy i komputerowymi systemami wizyjnymi zawierają one wiele zapytań do bazy danych?

A co z liniowymi edytorami wideo i silnikami fizycznymi gier wideo?

— Alex Jasmin
źródło

5

Spodziewałbym się, że generalny programista będzie miał przynajmniej wiedzę na temat technologii baz danych (relacyjnych lub innych) i będzie w stanie omówić zalety i wady korzystania z nich. W przeciwnym razie bałbym się, że wszystko, co potrafią, to upychać dane do płaskich plików.

— Barry Brown
źródło

4

Nie sądzę, aby pisanie zapytań było podstawowym wymaganiem dla programistów. Mimo to uważam, że programista, który potrafi pisać zapytania i projektować bazy danych, byłby bardziej wartościowy dla organizacji.

Jeśli jednak ten programista może pisać tylko zapytania typu „wybierz * z tblxxxx”, nie uważam tego programisty za eksperta. Podobnie, jeśli baza danych zaprojektowana przez tego programistę umieszcza relacje jeden do wielu w jednej tabeli zamiast dwóch tabel, nie uważałbym tego programisty za eksperta.

Oto jak wyjaśniam to osobom spoza IT. Specjaliści IT specjalizują się w niektórych obszarach, podobnie jak specjalizują się stolarze, elektrycy i hydraulicy w szanowanych dziedzinach. Zwykle nakładają się na niektóre umiejętności, ale nie są ekspertami we wszystkich obszarach. Elektryk może z łatwością wykonywać proste prace stolarskie, ale nie wróży dobrze próbując poradzić sobie ze skomplikowanymi konstrukcjami.

Podobnie, programista może i powinien wiedzieć, jak pisać lub manipulować prostymi zapytaniami i projektami baz danych, ale nie należy oczekiwać, że zaprojektuje złożoną strukturę danych.

— Michael Riley - AKA Gunny
źródło

3

Rozglądając się po naszym dziale, zależy:

Nasi programiści komputerów stacjonarnych / sieci / serwerów . Co najmniej wymagane do napisania podstawowych lub zaawansowanych instrukcji crud w zależności od ich specjalizacji. Do optymalizacji mamy kilku wyspecjalizowanych administratorów DB.
Nasi wbudowani programiści . Sporo osób nigdy nie przeszło „wybierz * z mytable”. Zmieniło się to jednak również w ciągu ostatnich kilku miesięcy wraz z wprowadzeniem sqllite do ich projektów.

— Carra
źródło