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

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.

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:

1. Są na ogół niedoświadczeni.
2. 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 .

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.

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

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.

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.

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.

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.

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.

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?

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.

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.

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.