Czy nadal istnieje potrzeba pisania SQL?

Czy przy tak wielu narzędziach ORM dla większości współczesnych języków nadal istnieje przypadek użycia do pisania i wykonywania SQL w programie, w obsługiwanym przez niego języku / środowisku? Jeśli tak to dlaczego?

Dla jasności: nie pytam, czy programiści muszą znać SQL, czy też powinienem mieć narzędzie SQL na pulpicie. Pytam konkretnie, dlaczego mógłbym mieć to w kodzie (lub config, czy cokolwiek innego) w przeciwieństwie do ORM.

• Bardziej wygodne jest pisanie SQL w celu wyszukiwania danych niż pisanie kodu proceduralnego.
• Twoja ORM, choć piękna w widoku, generuje przerażająco wolne SQL w niektórych krytycznych obszarach.
• Musisz skorzystać z funkcji udostępnianej przez RDBMS, która nie jest / nie może być udostępniona za pośrednictwem Twojego ORM.
• Za każdym razem, gdy piszesz SELECT * FROM..., Bóg zabija kociaka. I nienawidzisz kociąt.
• Nie używasz ORM, OOP ani nowoczesnego języka.

Pisanie złożonego SQL

ORM są świetne do podstawowych rzeczy. Jednak w skomplikowanych sytuacjach będziesz musiał napisać SQL.

Krótko mówiąc, z pewnością istnieje zapotrzebowanie na SQL i zawsze tak będzie.

• Wyświetlenia
• Wyzwalacze
• Ograniczenia
• Pakiety (SSIS, DTS itp.)
• Za każdym razem, gdy potrzebujesz precyzyjnie kontrolować przebieg wykonywania

ORM nie pomaga w budowaniu, dostrajaniu ani automatyzacji bazy danych. To po prostu daje alternatywny sposób interakcji z bazą danych po wykonaniu wszystkich tych czynności.

Pewnie:

• Zasadniczo ORM zawiera wiele, ale ostatecznie powinieneś wiedzieć, co dzieje się za kulisami. Ma to kluczowe znaczenie dla wydajności i skalowalności. Chociaż wewnątrz aplikacji nie piszę zbyt dużo SQL, ale z grubsza wiem, jak wygląda SQL lub DDL.
• Direct SQL często jest przyjemny w pisaniu zapytań tylko do odczytu. Znacznie łatwiej jest sformułować go w języku zapytań ORM, a także można ograniczyć zestaw wyników (np. „Wybierz identyfikator z .....”).
• ORM nie powinien w ogóle trzymać Cię z dala od SQL. Często używam SQL do zapytań ad-hoc bezpośrednio na kliencie DB (jak mysql-client). Daje to bardzo ładny, jednolity interfejs i funkcje grupowania.

ORM istnieją z powodu niedopasowania impedancji między naszymi powszechnymi relacyjnymi implementacjami DB a naszymi funkcjami języka OO. Są tylko pomostem, ale większość ludzi traktuje SQL jak ser Limburger w lodówce.

Jeśli możesz słusznie powiedzieć, że zawsze będziesz używać ORM lub innej abstrakcyjnej warstwy dostępu do danych zamiast traktować SQL / procedury składowane / widoki jako interfejsy pierwszej klasy, to prawdopodobnie lepiej byś nie dotknął SQL.

W praktyce nigdy nie widziałem projektu opartego wyłącznie na ORM, który nie wymagałby przynajmniej SQL-a do wysłania zapytania do bazy danych w celu ostatecznej weryfikacji.

ORM są narzędziem w przyborniku programistów. Mają swoje problemy. Oto niektóre przykłady:

• Nie można kontrolować sql
• Cierpi z powodu problemu n + 1

Jeśli wiesz, co robisz, możesz skutecznie użyć ORM do zastąpienia dużej części kodu typu CRUD. Nie są one jednak tak skuteczne w przypadku skomplikowanych rzeczy, są trudne do dostrojenia (wiesz, że wydajność jest jedną z kluczowych części projektu bazy danych, a nie emulacji obiektów) i są wręcz okropne i niebezpieczne w rękach kogoś, kto nie robi same nie rozumieją ani nie piszą SQL.

Chcę również zauważyć, że skomplikowane raportowanie nie jest łatwe do efektywnego wykorzystania w przypadku ORM. Co więcej, jeśli nie nauczysz się prostego języka SQL w łatwym języku, jak zdołasz napisać złożony SQL do raportowania? Nigdy nie pracowałem w aplikacji, która nie wymagała raportowania i często była dość skomplikowana.

ORM nie są w większości przydatne do procesów BI lub ETL. Nie są też przydatne do zapytań administratora bazy danych lub do znajdowania informacji w tabelach kontroli i cofania określonego zestawu zmian w bazie danych. Istnieje wiele rzeczy, które są najskuteczniej wykonywane za pomocą SQL. Aplikacja wykonująca zapytania do bazy danych stanowi niewielką część tego, co należy wykonać w celu przeszukania jej w środowisku Enterprise.

Widzę też wiele pytań o to, jak zrobić coś przy użyciu ORM, że plakat już wie, jak to zrobić w SQL. Miło jest uczyć się nowych rzeczy, ale kiedy powodują one dodatkowy czas i wysiłek bez rzeczywistego zysku w porównaniu z metodą oryginalną (i często prawdziwą utratą wydajności), dlaczego używasz ich innych niż są teraz „modne”.

Czasami klient chce tylko szybkiego i łatwego zapytania w celu zwrócenia danych do raportu, eksportu, zrzutu danych itp. I chce poczekać na opracowanie całego programu.

Ponadto dobry programista SQL zawsze może pisać szybsze, bardziej wydajne SQL niż jakikolwiek ORM, którego użyłem. Odkryłem również, że wiele osób ma po prostu punkt ORM na procedury składowane - naprawdę ignorując zalety ORM, ponieważ ORM nie są świetne dla złożonych procesów.

Ponadto, korzystając z bazy danych takiej jak Oracle z bardzo bogatym i wydajnym językiem procedur, możesz wiele zrobić bez potrzeby posiadania „programu”. PL / SQL na Oracle w odpowiednich rękach jest bardzo szybki i skuteczny.

Jeśli chcesz samodzielnie korzystać z bazy danych, tak. Większość ORM, których próbowałem użyć, po prostu nie była wystarczająca lub nie obejmowała mojej bazy danych. Poza tym, jak zamierzasz rozwiązywać problemy lub pisać niestandardowe zapytania, które nie są objęte?

Nadal jest wymagany do pisania wyzwalaczy i procedur przechowywanych. Procedury składowane mogły się obecnie nie podobać, ale w niektórych sytuacjach nadal są bardzo przydatne. SQL może być również wymagany w przypadku niektórych szczególnie owłosionych połączeń wielostolikowych.

Tak, możesz uniknąć pisania SQL. Ale zamiast tego skończysz pisać HQL (lub Linq lub DQL ...)!

Poważnie, jestem wielkim fanem ORM i myślę, że przez większość czasu można uniknąć używania czystego SQL. Ale musimy pamiętać, że ORM to tylko jedna wielka abstrakcja, a wszystkie duże abstrakcje przeciekają ...

(Ale o problemie N + 1: jest to związane z leniwym ładowaniem, a większość narzędzi ORM może w jakiś sposób żądać chętnego ładowania, unikając w ten sposób tego konkretnego problemu.)

ORM doprowadzi cię tylko do pewnego momentu. Ale zdarzają się przypadki, gdy trzeba wykonać naprawdę skomplikowane zapytanie ze skomplikowanymi połączeniami, podzapytaniami, związkami, minusami, funkcjami analitycznymi itp. To wtedy potrzebujesz SQL. Ale jak masz pisać skomplikowane zapytania, kiedy wszystkie proste zapytania pozostawiasz ORM?

Nawet jeśli nie trzeba było zapisywać go w kodzie, bardzo wygodnie jest go używać, gdy masz dostęp do terminala do serwera bazy danych.

Ponadto, większość z tego, co sprawia, że programowanie wyzwanie pracuje w ramach ograniczeń zestawy życiowe nas- często są pracy z starego kodu lub starymi wersjami baz danych i nie mają możliwości, aby zainstalować najnowszą bibliotekę ORM dla niezależnie od języka jesteśmy Praca z. W tej sytuacji będziesz potrzebować dowolnego narzędzia do dyspozycji.

Przez resztę czasu możesz nie potrzebować SQL do swoich CRUD, ale SQL to znacznie więcej niż proste zapytania SELECT, INSERT, UPDATE i podstawowe zapytania JOIN. Możesz robić z nim bardzo sprytne rzeczy i chociaż nie często z nich korzystasz, warto wiedzieć, czym one są.

Wydaje mi się, że coraz częściej znajdziemy się w świecie post SQL, jednak większość usług w chmurze korzysta z przechowywania tabel w języku innym niż SQL, a dla prostej pracy typu CRUD pełna moc SQL nie jest potrzebna. Ale to nie znaczy, że zrozumienie tego nie będzie wartościowe.

Ponadto, oczywiście, ktoś musi wiedzieć wystarczająco dużo, aby napisać lepszy system ORM, jeśli obecne nie mają zbyt wiele. Pomógłby im, gdyby znali SQL ...

W przypadku tworzenia aplikacji internetowych na dużą skalę jest to całkowicie niepotrzebne i może sprawić, że będzie to znacznie bardziej stresujące i czasochłonne, niż trzeba. Powodem tego jest to, że każda wielkoskalowa aplikacja powinna wykorzystywać warstwę trwałości pamięci (w pamięci RAM), która powinna być często używanymi częściami DB bazy danych w pamięci podręcznej.

Jeśli musisz robić rzeczy z urządzeniami mobilnymi itp., Które nie mają dużo pamięci do pracy, w których programowana aplikacja działa jako „klient” lub samodzielna aplikacja na urządzeniu mobilnym, tablecie itp. rzeczy takie jak używanie SQL są nadal powszechne i są ważne, ponieważ pamięć na urządzeniu jest tak mała, że ​​nie można buforować wielu rzeczy w pamięci.

Złożoność i ilość napisanego przeze mnie kodu SQL nie jest wystarczająca, aby podpięcie frameworka ORM było rozsądne.

(Piszę SQL może raz w miesiącu, jeśli)

Natknąłem się na wiele dużych korpusów z DBA, którzy aktywnie boją się deweloperów za pomocą narzędzi ORM.

Są to DBA, które są zaangażowane w strojenie i wydajność.

I tak, narzędziami ORM można zarządzać, aby robić takie rzeczy, ale widziałem miejsca, w których akceptują tylko procedurę przechowywaną (Serwer Sql) i pytają Cię o to, co robisz.

Ponadto narzędzia ORM mogą być poważnie nadużywane i produkować tak samo słabe Sql, jak samemu Sql.

Jeden biggie - migracje DDL i baz danych. Czasami musisz ręcznie zszyć te rzeczy, aby zaktualizować rzeczy bez niszczenia istniejących danych.