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?
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.
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 :)
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.
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.
Chyba tylko w CRUDach albo i nawet nie tam. ORMy są od lat w odwrocie, kiedy okazało się że zwyczajnie sie nie sprawdzają.
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
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
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.
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).
Robot: CCBot (2x)
