Czy SQL został wyparty przez ORM'y?

Odpowiedz Nowy wątek
2019-12-02 22:15
0

Praca praca... właśnie stawiam pierwsze kroki i mam taki problem.
Jak wyglądają bazy danych, czy można być progamistą jedynie specjalizującym się w bazach danych? Język SQL jest obecnie potrzebny czy został już wyparty/zastąpiony (nie wiem jak mogę to powiedzieć) przez orm-y?

edytowany 3x, ostatnio: cerrato, 2019-12-03 00:05

Pozostało 580 znaków

2019-12-02 22:23
5

Właśnie, przez ORM'y zaczyna brakować ludzi co znają się na bazach. Ponadto, ORM to jedno podejście, ale jest całkiem sporo projektów, nawet nowych gdzie składane sa SQL w kodzie, lub, gdzie operuje się tylko na procedurach SQL, a ktoś je musi pisać. Sporo raportów to tez SQL. Znam wielu programistów, którzy znają się dobrze na SQL i wewnętrznych frameworkach firmowych, które w zasadzie obudowują SQL. Nie powiem, że to dobre, bo takie podejścia dają dużo błędów, za dużo kodu SQL to problem z testowaniem, separacją odpowiedzialności, etc. etc. ale niemniej jest w tym robota i będzie nadal.

@somedev: "... kodu SQL to problem z testowaniem, separacją odpowiedzialności ...". Ze kwa co? A co powiesz na przyklad na temat "separation of concepts" w przypadku annotations umieszczonych w entities? O testowaniu w przypadku final'nego manager'a Doctrine to juz w ogole nie wspomne. Jakbys sobie potestowal stare dobre php-owe PDO to bys takich bzdur nie wypisywal. - Constantic 2019-12-03 12:52
Widzę, że serio masz problem z cytowaniem, ale nie tylko. Jeśli masz inny pogląd, to bardzo się cieszę, możemy podyskutować. Niemniej kulturalnie, przedstawiając argumenty, a sypiąc hasłami i niedopowiedzeniami, nawet nie wiem co komu zarzucasz. Nie widzę tutaj zatem płaszczyzny do polemiki. - somedev 2019-12-03 13:52
z tego co pamiętam to @Constantic miał już kiedyś odpoczynek od forum za jakąś kłótnię - chyba z @komuher - no i widać wraca do formy - superdurszlak 2019-12-04 11:31
Może to jedyne miejsce gdzie buduje swoje poczucie wartości ¯_(ツ)_/¯. Nie każdemu życia się układa. - somedev 2019-12-04 11:54
nie wiem, choć po części rozumiem, klepanie CRUDów jest naprawdę frustrujące, a z ORMem pod pachą to już w ogóle no-brainer - widać piana znalazła ujście przez internet :) - superdurszlak 2019-12-04 11:59
Pisał cos o PHP... wiadomo niektórzy dostają uszkodzenia mózgu na pozytywnie jak @czysteskarpety a inni... no cóż tylko współczuć nieszczęścia. - somedev 2019-12-04 12:12

Pozostało 580 znaków

2019-12-02 22:24
1

SQL zastąpiony? SQL rządzi:)
https://spectrum.ieee.org/vie[...]-of-most-indemand-tech-skills


Pozostało 580 znaków

2019-12-02 22:47
cmd
2

W skrócie tak. SQL i administracja bazami danych nigdzie się nie wybiera. Nie jest to może najbardziej porywająca część IT, ale zapotrzebowanie będzie raczej zawsze na taki profil ludzi.

Język SQL jest obecnie potrzebny czy został już wyparty/zastąpiony (nie wiem jak mogę to powiedzieć) przez orm-y?

ORMy jak wiemy to tylko nakładka na SQL. Więc ciężko mówić że ORMy wypierają SQL, raczej tylko po części jego znajomość u deverloperów :)

edytowany 1x, ostatnio: cmd, 2019-12-02 22:51

Pozostało 580 znaków

2019-12-02 22:51
0

Jest potrzebny i trzeba znać podstawy dla programisty. W zależności od firmy/projektu trzeba znać mniej lub bardziej zaawansowanie.
Czasami projekt wspiera tylko jedną bazę i wtedy ta wiedza automatycznie rośnie przy robieniu kolejnych ticketów, ficzerów i bugfixów.

Można się specjalizować w przetwarzaniu danych a nie stricte programowaniu i jeśli jest to mała i średnia skala to SQL jest konieczny.

Poza strojeniem bazy, dbaniem, żeby jakaś procedura nie poszła, po zł jest ścieżka rozwoju. - somedev 2019-12-02 22:54

Pozostało 580 znaków

2019-12-02 23:08
8

Nawet gdyby ORMy zamiast upośledzenia osiągnęły doskonałość, to nie wyobrażam sobie sytuacji, gdy programista ich używający nie zna SQL. Często jest potrzeba zobaczenia polecenia SQL wygenerowanego przez ORM lub ręcznego sprawdzenia lub edycji czegoś w bazie. Zdarza się, że trzeba napisać jakiś skrypt, utworzyć trigger czy skorzystać z Dappera w projekcie, w którym nie ma sensu używać jakiegoś bardziej zaawansowanego ORMa. Nie pamiętam, żebym widział ogłoszenie o pracę dla full-stack developera, w którym nie byłby wymieniony SQL w wymaganiach.

edytowany 1x, ostatnio: Burmistrz, 2019-12-02 23:09

Pozostało 580 znaków

2019-12-03 00:04
0

Wydaje mi się, że "specjalista od baz danych", który zna jedynie ORM'y, ale nie ma pojęcia czym jest SQL, to taki anachronizm w stylu "czy mam się uczyć PHP, czy wystarczy WordPress" :P


That game of life is hard to play
I'm gonna lose it anyway
The losing card I'll someday lay
So this is all I have to say

Pozostało 580 znaków

2019-12-03 01:41
6

Chyba tylko w CRUDach albo i nawet nie tam. ORMy są od lat w odwrocie, kiedy okazało się że zwyczajnie sie nie sprawdzają.


Masz problem? Pisz na forum, nie do mnie. Nie masz problemów? Kup komputer...
Nie sądzę, możesz uzasadnić swoją wypowiedź? Moim zdaniem znacznie skracają proces developerki i ułatwiają utrzymanie kodu, a to są często najistotniejsze koszty długoletnich projektów. Do tego zmniejszają koszt wejścia w projekt dla młodych stażem programistów. Dopiero w wąskich gardłach należy przesiąść się do sql. - ŁF 2019-12-03 13:35
A w jakim projekcie, poza generycznym CRUDem, potrzeba wyciągnąć z jakiejś tabeli wszystkie kolumny bez wyliczania czegokolwiek w query? Nie widze też zupełnie gdzie ci coś ułatwiają, przecież i tak masz jakieś wydzielone "repozytorium" i masz jakis model domenowy który z niego wychodzi. To gdzie ten zysk? O debugowaniu nawet nie wspominam, bo znów dramat cośtam się magicznie dzieje i jak nie działa to można tylko rozłożyć ręce. - Shalom 2019-12-03 14:01
Regenerujesz model bazy danych, kompilujesz aplikację i często już na tym etapie wiesz, że gdzie trzeba kod poprawić/zaktualizować, ewentualnie (code-first) tworzy/aktualizuje strukturę bazy na podstawie modeli. Oszczędza czas przy testach i zmniejsza prawdopodobieństwo wprowadzenia regresji (nawet z warstwą repozytorium nad ORM możesz się pomylić i nie zaktualizować nazwy czy typu pola), a więc utrzymanie kodu staje się tańsze. W C# umożliwia pisanie lambd/EM do przetwarzania danych. Co zaś się tyczy debugowania sql, to od tego są narzędzia typu profiler/plan zapytania. - ŁF 2019-12-11 10:22
zmniejsza prawdopodobieństwo wprowadzenia regresji przecież testy od razu wyłapią ci że coś się zmieniło i nie działa, więc trochę tego nie widzę. Chyba że nie masz testów... :) typu profiler/plan zapytania -> ale przecież właśnie w tym rzecz, ze sql jest generowany gdzieśtam jakośtam, więc co ci da plan zapytania, skoro nie możesz na to zapytanie wpłynąć? :) To chyba tylko dla własnej satysfakcji o, już wiem czemu to nie działa. - Shalom 2019-12-11 10:52
Testy idą po kompilacji i wymagają chwili na namierzenie źródła problemu. Kompilacja pokazuje od razu źródło. Jeśli chodzi o generowanie sql przez ORM, to zwykle masz wpływ na sql przez odpowiednie skonstruowanie zapytania w języku wysokiego poziomu (lambdy/EM), choć czasem to nie wystarczy. Słowo-klucz: czasem. - ŁF wczoraj, 13:44

Pozostało 580 znaków

2019-12-03 07:47
0

Co ci przyjdzie po tych ORM'ach jak klient przyjdzie i powie, że podsumowanie raportu mu się nie zgadza? Albo jak "baza danych działa wolno"? To uproszczenie, ale dzisiaj to właśnie ORM'y mają coraz mniejszą rację bytu. Jeżeli nie potrzebujesz SQLa to możesz użyć obiektowych baz danych, jak potrzebujesz relacji, to potrzebujesz też SQL.

@piotrpo: "... potrzebujesz relacji, to potrzebujesz też SQL ..." A co ma piernik do wiatraka ? NIe wiem w jakim ORM-ie robisz, ale jakos moje relacje sa obslugiwane w Doctrine. - Constantic 2019-12-03 12:57
@Constantic: dalej w uproszczeniu - jeżeli wszystko co ma robić twoja aplikacja to CRUD na pojedynczych encjach - użyj jakiegoś MongoDB - będzie prościej. Jeżeli używasz RDBMS to z jakiegoś powodu. Jeżeli korzystasz np. z możliwości raportowania, wyszukiwania, agregowania, to użycie RDBMS ma sens, tylko wtedy potrzebujesz właśnie tego nieszczęsnego SQL'a. Jeszcze inaczej: jeżeli nie używasz SQL, to wybrałeś zły typ bazy danych. - piotrpo 2019-12-03 21:49
Błędne "podsumowanie raportu" nijak ma się do ORM, to błąd w logice kodu, który to podsumowanie robi, a nie mappera. - ŁF 2019-12-11 10:24
@ŁF: jasne, tylko pytanie brzmi - jak nie znając SQL udowodnisz, że program zsumował wszystkie możliwe tabelki we właściwy sposób? Najprościej to zrobić prostym zapytaniem z poziomu bazy danych. - piotrpo 2019-12-11 10:46
Ale co tu udowadniać i komu? Przecież tak jak możesz rąbnąć się w kodzie używającym ORM, tak i możesz się pomylić w sql. - ŁF wczoraj, 13:35

Pozostało 580 znaków

2019-12-03 08:47
1

Krótka odpwiedź: Nie.
Dłuższa odpowiedź: Oczywiście, że nie.

Pozostało 580 znaków

2019-12-03 09:18
6
Shalom napisał(a):

Chyba tylko w CRUDach albo i nawet nie tam. ORMy są od lat w odwrocie, kiedy okazało się że zwyczajnie sie nie sprawdzają.

No bez przesady ;) Często jak ktoś tak mówi, to duża część ludzi ma w myślach powrót do sklejania stringów w kodzie, chodzeniu po datasetach i konwersji typów danych na natywne dla języka łącznie z kodowaniami. To za daleko idący odwrót. Po prostu nie myśli się o bazie już jako o stałej warstwie prezystencji pomijając czym ta baza jest. Moim zdaniem ORM ma się dobrze jako ogólnie DAL, czy nawet takie ef robi dobrze, za DAO. Po prosty trzeba mieć świadomość, żeby nie targać z pół bazy do kontrolera, bo ktoś w repo wymyślnie zwraca IEnumerable całej dziedziny, czy postanawia sobie raporty liczyć metodami w kodzie i targa nawet więcej niż pół bazy. Ciekawe też, są przypadki struktur tabelarycznych przypominających graf pełen i tak napisanie "repozytorium", że chcąc wyciągnąć nazwę klienta a targa klienta, z oddziałami, zamówieniami, osobami kontaktowymi etc.

Żeby tak się nie działo, należy projektować aplikacje z głową. Np. zwracać z bazy tylko 1 klienta bez relacji i mieć od tego metodę, lub zwrócić dane tylko do tabeli, żeby zrobić kartotekę klientów i to tez z jakiego zakresu dziedziny, czyli stronicować. Raporty czy cięższe analizy pisać w SQL i zwracać procedurą jak z tabeli czy widoku, ale za pomocą ORM. Warto też projektować płaską strukturę bazy danych i ją normalizować.

Rezygnacja z ORM to znów problemy z transakcjami, mapowaniem na obiekty, konwersją typów, sklejaniem stringów w n miejscach ( no można zamknąć wszystko w DAO, ale tak się nie dzieje jak można "legalnie" napisać SQL, no a, że nie w tej warstwie...).

Zawierzanie w magiczność ORM, że Dev sobie napisze wesołą twórczość, a ORM magicznie nie wytarga połowy bazy, nie zaciągnie zależności etc. etc. można włożyć pośród bajki, ale nie należy cofać się 30 lat do tyłu tylko używać ORM jako narzędzie świadomym jego ograniczeń (jak każdego narzędzia).

Pokaż pozostałe 4 komentarze
Pierwsze programy pisałem około 1999/2000. - Satanistyczny Awatar 2019-12-03 17:31
No to powinieneś widzieć ten wieczny życia krąg już ;p - somedev 2019-12-03 17:34
Nie. Zaczynałem gdzieś w okolicach czwartej klasy podstawówki od TP, jak liczyć zabawy z qBASIC to trzeciej. - Satanistyczny Awatar 2019-12-03 21:28

Pozostało 580 znaków

Odpowiedz
Liczba odpowiedzi na stronę

2 użytkowników online, w tym zalogowanych: 0, gości: 0, botów: 2

Robot: CCBot (2x)