Czy SQL jest ważny, jeśli dobrze znam frameworki ORM? [Zamknięte]


50

Nie mam żadnego poważnego doświadczenia w SQL, a nawet nienawidzę pisać SQL zamiast LINQ. Jestem wystarczająco zadowolony z ORM.

Czy z punktu widzenia pracodawców i sektora ważna jest znajomość języka SQL? Czy muszę to opanować? Czy firmy, które wolą czysty SQL niż frameworki ORM, są „dinozaurami” w świecie programowania?


14
Czuje się staro. SQL został zaabsorbowany na tyle, że teraz możesz poważnie zadać to pytanie.
Mark

11
@Mark: Być może możesz poważnie zadać pytanie, ale odpowiedź jest nadal taka sama.
Adam Robinson

30
czy znajomość arytmetyki jest nadal ważna, jeśli mogę użyć kalkulatora?
Steven A. Lowe,

4
NHibernate bez znajomości SQL Profiler i tego, jak łaskotać jego brzuch, aby używać JOIN, to dżihad wydajności, który czeka na Twój serwer bazy danych
Chris S

2
Czy musisz znać HTML, jeśli możesz używać Dreamweaver?
Tulains Córdova,

Odpowiedzi:


63

Trudno to wytłumaczyć wielu programistom, ponieważ jeśli znasz tylko podstawowy SQL, to tak naprawdę nie daje ci to przewagi nad kulą ORM. Bardziej zaawansowane koncepcje SQL stanowią jednak istotną część różnicy między aplikacjami, które działają, a aplikacjami wysokiej jakości (w szczególności szybkimi i niezawodnymi).

Zakładam, że ktoś inny projektuje dla ciebie bazy danych, ponieważ robienie tego bez znajomości SQL jest nie do zniesienia. Ale nawet jeśli rozwijasz się tylko przeciwko nim, oto tylko częściowa lista wszystkich rzeczy, które ORM-y nadal robią źle lub wcale:

  • Zapytania rekurencyjne i / lub hierarchiczne
  • Parametry opcjonalne (w szczególności przekładając je na predykaty zasięgu)
  • Typy danych zdefiniowane przez użytkownika
  • Typy specyficzne dla platformy (hierarchyid SQL i TVP, tablice Oracle i zagnieżdżone tabele itp.)
  • Wstawia / aktualizuje / aktualizuje / usuwa
  • Wskazówki dotyczące indeksu
  • Wskazówki dotyczące blokowania (szczególnie blokady aktualizacji i nieczytelne odczyty)
  • Obsługa błędów
  • Sprzężenia zewnętrzne - ich zestawy wyników słabo odwzorowują model OOP, wiele ORM ma swój własny język zapytań, ale jest podobny do znajomości samego SQL;
  • Modularyzacja poprzez procedurę przechowywaną i UDF, szczególnie wbudowane zapytania UDF i zapytania CROSS APPLY
  • Zastosowanie OUTPUT / RETURNING do przemieszczania danych do wielu tabel
  • Wydajne zapytania stronicowania
  • Zapytania oparte na funkcjach okienkowania (rownum, ranga, partycje)

Lista jest długa - wiele z nich to rzeczy, których nowicjusz DBA nigdy nie musiał robić, a początkujący programista nawet o nich nie słyszał - ale są one bardzo ważne w aplikacjach na większą skalę.

ORM są naprawdę świetne w przyspieszaniu naprawdę nudnego kodu SQL - to znaczy w całym powtarzalnym CRUD i mapowaniu i innym kodzie instalacyjnym, więc absolutnie nie ma się czego wstydzić i nie słuchać nikogo, kto mówi, że są źli. Ale na pewno nadal musisz się uczyć i tak, nawet opanować SQL, i być przygotowanym na rozwijanie się w surowych poleceniach / zapytaniach DB, gdy ORM nie naciska.


Zgadzam się z większością twoich punktów, ale jeśli chodzi o połączenia zewnętrzne: tak, źle mapują one w OOP, ale myślę, że odpowiednik OOP (np. GroupJoinW LINQ) jest znacznie lepszy.
sick

@svick: Ma swoje zastosowania, ale to nie to samo. Spróbuj emulować pełne połączenie zewnętrzne za pomocą GroupJoin.
Aaronaught

Tak, to nie to samo. I myślę, że to, czego potrzebujesz przez większość czasu, to właściwie GroupJoin. Po prostu ludzie, którzy są przyzwyczajeni do SQL, natychmiast myślą w takich przypadkach o sprzężeniu zewnętrznym, a następnie pytają, jak je przetłumaczyć na LINQ. To nie jest właściwe podejście. Nie powinieneś próbować tłumaczyć SQL na LINQ, powinieneś tłumaczyć to, czego potrzebujesz bezpośrednio.
svick,

@svick: Dzięki za wskazówkę. Nienawidzę ciągnąć rangi ale po całorocznej przerwie jestem nadal jednym z najlepszych autorów, zarówno dla SQL i Linq na przepełnienie stosu, więc jestem całkiem pewien, że rozumiesz różnicę w podejściu. Pełne sprzężenia są rzadkie, ale czasami są tak naprawdę potrzebne i po prostu nie ma analogii w Linq. Uzyskanie tego samego zestawu wyników jest dość nieuporządkowane i nieefektywne , niezależnie od jego struktury .
Aaronaught

Wygląda na to, że się zgadzamy. W większości przypadków tak naprawdę nie chcesz łączenia zewnętrznego. Ale kiedy to zrobisz, trudno jest przetłumaczyć go na LINQ.
svick,

90

Absolutnie! SQL jest nadal lingua franca baz danych i chociaż możesz wiele zrobić z ORM, musisz zrozumieć SQL, aby zrozumieć decyzje podejmowane przez ORM i generowany przez nich SQL. Ponadto nadal istnieje wiele rzeczy, które musisz zrobić z niestandardowymi kodami SQL i procedurami składowanymi. Przepraszamy, brak darmowego lunchu.


6
W rzeczy samej. Musisz na przykład wiedzieć, jaki jest wpływ różnych instrukcji łączenia i jak wpływa na wydajność.
Chiron,

15
+1 Brak darmowego lunchu! O co właściwie pytają wszystkie pytania, czy ignorancja jest w porządku?
benzado

7
@benzado: Nie sądzę, że jest to uzasadnione dla SQL, ale musisz wybrać ignorancję niektórych rzeczy; jest zbyt wiele technologii (nawet tych dobrych!), aby naprawdę je wszystkie poznać. Więc myślę, że można zadać pytanie „czy X jest niepotrzebne, jeśli znam Y naprawdę dobrze, czy robię Z?”
Craig Walker

2
@Craig Zgadzam się, że jest zbyt wiele do nauczenia się, ale programista naprawdę powinien mieć podstawową wiedzę na temat poziomów poniżej, w których pracuje.
benzado

2
Bazy danych @Craig Walker to kluczowa wiedza dla większości aplikacji biznesowych, co nie jest miłe.
HLGEM,

25

Tak, nadal musisz znać SQL. ORM są bardzo nieszczelną abstrakcją i nie zapewniają dostępu do pełnej mocy SQL. W przypadku zabawek możesz mieć ograniczoną znajomość języka SQL. W przypadku aplikacji korporacyjnych musisz zrozumieć bazę danych, aby uzyskać przyzwoitą wydajność z ORM. Istnieje również wiele zadań, które są znacznie łatwiejsze do wykonania w SQL niż w języku aplikacji. Widziałem, jak programiści Java spędzają dni pisząc kod, aby zrobić coś, co mogłoby zostać zakodowane w SQL w ciągu godziny. Znajomość SQL jest bardzo cenna dla każdego, kto pisze aplikacje korzystające z relacyjnej bazy danych.


14

Umiejętność posługiwania się językiem SQL jest dziś niezbędną umiejętnością w dziedzinie IT. LINQ to technologia Microsoft Only. Zastosowania SQL wykraczają poza tworzenie aplikacji internetowych i aplikacji klient / serwer. Nie możesz modelować baz danych i wykonywać ETL, jeśli nie jesteś dobry w SQL. Może nie być konieczne opanowanie dialektów SQL używanych w ORACLE i SQL Server dla ich produktów Data Warehous, ale powinieneś znać standardowy SQL. Podstawy SQL są proste, na początek jest mnóstwo materiałów.


1
Każdy, kto wie, jak działa LINQ, będzie mógł nauczyć się podstawowego języka SQL w ciągu jednego dnia. To okropny argument do nauki SQL.
Boris Yankov,

6

Jeśli korzystasz z bazy danych SQL, musisz zrozumieć kod SQL generowany przez ORM. Musisz zrozumieć pojęcia związane z bazami danych SQL i zrozumieć, czego Twoja ORM nie może dla Ciebie zrobić. ORM ułatwiają życie (i tak, myślę, że praca bez jednego kwalifikuje cię w wielu przypadkach jako dinozaura), ale są narzędziami (do abstrakcji rzeczy, które znasz), a nie kulami (aby uniemożliwić ci naukę).

Jeśli nie chcesz uczyć się SQL, to nie masz żadnego interesu, dotykając baz danych SQL, z ORM lub bez, i powinieneś znaleźć inny rodzaj pracy.


Chociaż zgadzam się, że znajomość SQL jest bardzo przydatna - zasadniczo obowiązkowa - nie zgadzam się z twoimi powodami. Z tego powodu musisz znać ASM i architekturę procesora przed napisaniem jakiegokolwiek programu, ponieważ języki wysokiego poziomu ułatwiają to, ale są narzędziami (do abstrakcyjnych rzeczy), więc jeśli odmówisz nauki instrukcji i architektury procesora, nie będziesz musiał używać komputer. <--- Nie ma sensu. Prawdziwym powodem, dla którego potrzebujesz, jest to, że narzędzia ORM są jeszcze w powijakach; Nie zdziwiłbym się, gdyby od 5 do 10 lat znajomość SQL przestała być potrzebna
Thomas Bonini

Języki wysokiego poziomu są zbudowane w taki sposób, że uniemożliwiają zapoznanie się z podstawową architekturą, prawda. Jest to możliwe, ponieważ domena jest współmierna z architekturą bazową. ORM to jednak inna sprawa. Jestem wielkim fanem ORM, ale nie sądzę, że kiedykolwiek nadejdzie dzień, w którym będziesz mógł użyć jednego bez znajomości SQL (lub czegokolwiek, co wykorzystuje bazowa baza danych). Modele obiektowe i relacyjne są zasadniczo niewspółmierne i myślę, że zawsze będą koncepcje, które nie tłumaczą się między sobą. Poza tym mówię o dzisiejszych ORM, a nie o przyszłości
Marnen Laibow-Koser

3
+1: „Jeśli odmówisz nauki SQL, nie będziesz miał żadnego interesu w dotykaniu baz danych SQL, z ORM lub bez, i powinieneś znaleźć inny rodzaj pracy.”
Wektor

2
Głosowałbym za tym milion razy, gdybym mógł. jest o wiele za dużo osób, które nie mają żadnego interesu, dotykając baz danych SQl z powodu ich ogólnej niekompetencji i niezrozumienia, czym się zajmują. Robią spustoszenie, gdziekolwiek idą, tworząc encykliki performanc i pisząc raporty (z których podejmowane są rzeczywiste decyzje biznesowe), które mają gorsze wyniki, nigdy nie zauważając, ponieważ są świadomie nieświadomi SQl, jakby to była jakaś odznaka honoru, aby zdystansować bazę danych ma to kluczowe znaczenie dla ich aplikacji.
HLGEM,

1
+1 za „narzędzia (do abstrakcji rzeczy, które znasz), a nie kule”.
sholsinger

4

Przyznaję, że jestem zagorzałym fanem ORM i od lat głoszę zalety ORM i miałem wiele do powiedzenia na temat tego, dlaczego ORM przebija SQL.

ALE...

Muszę przyznać, że SQL jest całkowicie i całkowicie wymagany w prawdziwym świecie i każdy programista powinien dobrze rozumieć SQL.

Procesy SQL są szybsze niż ORM w prawie wszystkich przypadkach. Mimo że w większości przypadków możesz optymalizować wyjście ORM, spraw, aby było to bardzo blisko procesem SQL.

Czasami potrzebujesz trochę ciężkiego SQL, aby uzyskać wymagany wynik, a te zapytania potworowe są łatwiejsze i szybsze do utworzenia w procesach SQL.

Tylko moje dwa bity.


4

Nadejdzie czas, gdy będziesz musiał zoptymalizować coś złożonego, co tworzy ORM. W tym momencie zazwyczaj masz bardzo złożone zapytanie do rozbicia. Jeśli nigdy nie nauczyłeś się podstaw, jak możesz zacząć uczyć się SQL z zaawansowanymi funkcjami? Nie zrozumiesz wystarczająco, aby zacząć. ORM w rękach osoby rozumiejącej SQL - dobre narzędzie. ORM w rękach kogoś, kto w ogóle nie zna SQL-a czeka katastrofa.

Jednym z powodów, dla których SQL ma kluczowe znaczenie dla zrozumienia baz danych, jest to, że programiści aplikacji nie myślą naturalnie o zestawach danych. Ale jedynym sposobem, w jaki bazy danych działają w ogóle skutecznie, są zestawy. Musisz nauczyć się myśleć w zestawach, zanim nawet spróbujesz użyć ORM.


3

Często zmuszam się do wymuszania zapytań w ramach ORM. I choć większość ma swój własny język zapytań, wszystkie są inspirowane sql, kod zmienia się w sql, a ty musisz zrozumieć, co się dzieje, czytając ten sql, gdy (nie, jeśli, kiedy) coś pójdzie nie tak lub źle.
Więc nawet jeśli nie piszesz bezpośrednio sql, rozumiejąc go poza poziomem podstawowym (chociaż prawdopodobnie nie będziesz musiał uczyć się różnych rzeczy na temat pisania procedur przechowywanych, wyzwalaczy itp., Jeśli wszystko, co musisz zrobić, to uzyskać dostęp do baz danych) powinien znać język na tyle, aby zrozumieć wygenerowany kod i dostosować go w razie potrzeby.


3

Zanim zacznę mówić o tym pytaniu, najpierw trochę wstępu; Uwielbiam ORM. I nienawidzę SQL. Uwielbiam ORM, ponieważ ukrywają nieprzyjazny dla użytkownika bałagan, jakim jest SQL, i zapewniają przyjemny, zintegrowany z językiem sposób radzenia sobie z bazą danych.

Muszę jednak przyznać, że SQL ma wiele zalet, z których większą jest precyzja. Mogę niemal kłócić się o złożoność zapytania SQL, bez szczegółowej wiedzy o podstawowym schemacie bazy danych, po prostu przechodząc przez zapytanie. Dlatego kiedy korzystam z SQL, zawsze jestem czujny i zawsze mam intuicję, dokąd zmierza złożoność komponentu.

Z drugiej strony, gdy używam ORM, jestem tak przytłoczony łatwością integracji z bazą danych, że dosłownie zapominam, że nawet istnieje baza danych. To mnie spieprzyło wiele razy. Wiele razy w przeszłości dzwoniłem do niewinnie wyglądających metod ORM, które za kulisami nazywają masywne i przerażające połączenia z bazą danych, które niszczą wydajność.

Dlatego dla mnie prawda jest gdzieś pośrodku. Uwielbiam używać ORM i nadal będę to robić, ale muszę być bardziej ostrożny i zawsze badać konsekwencje (na poziomie SQL) każdego wywołania metody ORM. Znajomość implikacji warstwy abstrakcji jest czystym złotem w tym biznesie i uzasadnia użycie abstrakcji. Wszystko inne przypomina strzelanie sobie w stopę.


3
Myślę też, że czasami (nawet przy zwykłym SQL) ludzie zapominają, że to, że zwrócił zestaw danych, nie oznaczało, że był to prawidłowy zestaw danych. Myślę, że łatwiej jest zapomnieć o ORM, gdy zakładasz, że zrobił to poprawnie, ponieważ tak naprawdę nie rozumiesz, co on zrobił.
HLGEM

Nie zgadzam się, że ORM jest mniej złożony niż SQL. Dzięki SQL możesz pobierać dane bez programowania. SQL nie jest językiem programowania, ale językiem deklaratywnym, więc nie ma struktur typu „czas na” ani „jeśli-to”.
Tulains Córdova,

1
Deklaratywny język programowania jest nadal językiem programowania. SQL jest językiem programowania specjalnego przeznaczenia i tak, w przeważającej części jest deklaratywny. Jeśli chodzi o treść twojego komentarza, nie rozumiem. SQL, choć nie jest językiem programowania ogólnego przeznaczenia, wciąż jest językiem. Nadal musisz znać składnię, jej ograniczenia i wady.
Charalambos Paschalides,

2

Jeśli wszystko, co kiedykolwiek musisz zrobić, to interakcja z bazą danych tylko przez aplikację, którą budujesz, prawdopodobnie nie potrzebujesz jej. W niektórych mniejszych firmach lub zespołach programistów może być konieczne wsparcie. O wiele łatwiej jest połączyć się z bazą danych klienta i uruchomić kilka instrukcji SQL, aby zobaczyć, co się dzieje z ich danymi.


Kto musi wchodzić w interakcję z bazą danych TYLKO za pośrednictwem aplikacji, którą tworzy?
Tulains Córdova,

2

Nawet przy dobrej, dojrzałej ORM nieuchronnie spotkasz się z sytuacjami, w których emituje trochę nieefektywnego SQL i znacznie ułatwi ci życie, jeśli potrafisz zrozumieć, co się dzieje w wygenerowanym SQL. To powiedziawszy, jeśli jesteś bardzo biegły w ORM i wiesz, jak używać profilera dla wybranej bazy danych, możesz z łatwością „sfałszować go, aż go stworzysz”.


1

Odpowiedź na wszystkie te pytania („czy muszę znać X?”) Brzmi „naucz się, gdy będziesz go potrzebować, jeśli będziesz go potrzebować”.

Ważne jest, aby nie wpaść w pułapkę robienia rzeczy mniej efektywnie, ponieważ nie jesteś świadomy lub nie chcesz nauczyć się efektywnego sposobu ich wykonywania.

W tym konkretnym przypadku, na przykład, co robisz, jeśli zdajesz sobie sprawę, że w twoim programie wystąpił błąd, który PostCountczasami powodował niedokładność pola tabeli użytkowników.

Naprawiłeś błąd i teraz musisz zaktualizować PostCount dla wszystkich użytkowników. Jak ty to robisz?

Jeśli napiszesz mały skrypt za pomocą ORM, aby to zrobić, będziesz bardzo nieefektywny; zrobi to bardzo proste zapytanie SQL.

Ponieważ te sytuacje są dość powszechne, obawiam się, że wpadłeś w pułapkę opisaną powyżej!


2
Zgadzam się: jeśli nie znasz SQL, często piszesz dziesiątki linii kodu, aby zrobić to, co mogłeś zrobić za pomocą pojedynczego zapytania SQL.
benzado

2
ponownie „naucz się go, gdy będziesz go potrzebować po raz pierwszy”: ro-che.info/ccc/11.html
MatrixFrog,

1

Tak, nadal potrzebujesz SQL.

Nie przeskakuj do założenia, że ​​coś „starego” jest w jakiś sposób niegodne rozważenia. Tak zwane „starsze” technologie to te, które nadal istnieją po próbie czasu. Nie nazywamy komputerów Wang „dziedzictwem”, zawiodły i zniknęły.

Jeśli pytasz mnie, czy przeszkadza mi to, że mój bank prawdopodobnie używa COBOL na komputerze mainframe lub IBM i? Absolutnie nie. Są to solidne, sprawdzone i prawdziwe technologie. Zgadnij, głównie używają DB2 SQL. Jestem znacznie szczęśliwszy, ufając moim pieniądzom, niż w oprogramowaniu opracowanym w modnym języku miesiąca.

Dinozaury przetrwały na tej ziemi znacznie dłużej niż my, ludzie. A jeśli czytasz Jurasic Park (tak, książki są lepsze niż filmy), to pytam cię, czy naprawdę chcesz zmierzyć się z paczką hiper-sprytnych welociraptorów, czy z zawziętym T-Rexem, który nigdy się nie poddaje? Nie gryź się, nie doceniając „dinozaurów”. ;-)


0

Oprócz gier i badań (głównie statystycznych), z którymi nie mam doświadczenia, wydaje się, że dostęp do baz danych i operacje są jednym z niewielu obszarów, w których błędne decyzje prowadzą do bardzo dużego spadku wydajności. Wierzę w mocniejsze abstrakty baz danych w kodzie i wierzę, że linq, który łączy operacje bazy danych z językiem programowania, daje ci wszystkie narzędzia tego języka (sprawdzanie typu, sprawdzanie składni, wszystkie rzeczy, które lubisz w Twój język programowania), a jednocześnie daje ci mnóstwo mocy do robienia tego, co chcesz, jest absolutnie niesamowity. Niestety nadal nie zawsze działa. Oznacza to, że jeśli warstwa abstrakcji źle popełni optymalizacje, być może będziesz czekał na wynik sekund zamiast mikrosekund lub minut zamiast sekund na wynik. Ponieważ są to bardzo zauważalne czasy, musisz je zoptymalizować, w przeciwnym razie aplikacja nie będzie „działać”: wydajność staje się największym problemem aplikacji. Oznacza to, że musisz zbliżyć się do metalu i zoptymalizować rękę.

Kiedy dojdziemy do tego, że manipulowanie dużymi zestawami danych zajmuje na przykład 3 ms przy wykonywaniu ręcznie i 100 ms, gdy pozwalasz, aby warstwa abstrakcji zrobiła to za ciebie, za wszelką cenę pozwól, aby warstwa abstrakcji poradziła sobie z tym za ciebie, ponieważ możesz być 30 razy wolniejszym, ale nadal (prawdopodobnie w przypadku większości aplikacji) jesteś wystarczająco szybki. Rzeczywistość jest jednak taka, że ​​kiedy patrzysz na zoptymalizowane rozwiązania, w których masz czas reakcji 200 ms, a gdy warstwa abstrakcji sobie z tym poradzi, algorytm przyjmuje „tylko” 10-krotne trafienie wydajnościowe, masz 2 sekundy opóźnienia, a potem bardzo Ci zależy, od nie tak szybkiego, aż po boleśnie powolne. Widząc to rozwiązania relacyjnych baz danych nie skalują się dobrze, Nie sądzę, że zostanie to rozwiązane za dwa lub trzy lata. Oznacza to, że nadal będziesz musiał przejść do samego systemu od dłuższego czasu, jeśli chodzi o większe bazy danych, lub Twoja aplikacja będzie tak wolna, że ​​nie będzie w stanie wytrzymać konkurencji.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.