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

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?

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.

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.

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.

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.

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.

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.

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.

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.

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

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.

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

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!

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”. ;-)

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.