Czy SQL został wyparty przez ORM'y?

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?

6

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.

5

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 :)

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.

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.

1

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

9

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

1

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.

2

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

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

6

Rezygnacja z ORM to znów problemy z transakcjami, (...) sklejaniem stringów w n miejscach

Co to za bzdury? o_O Jedno z drugim nie ma nic wpsólnego. Zapewniam cię że są biblioteki które pozwalają wygodnie korzystać z sqlowych baz danych, a jednocześnie nie dają raka jak hibernate i pozwalają wygodnie kontrolować zapytania.

2
Shalom napisał(a):

Rezygnacja z ORM to znów problemy z transakcjami, (...) sklejaniem stringów w n miejscach

Co to za bzdury? o_O Jedno z drugim nie ma nic wpsólnego. Zapewniam cię że są biblioteki które pozwalają wygodnie korzystać z sqlowych baz danych, a jednocześnie nie dają raka jak hibernate i pozwalają wygodnie kontrolować zapytania.

Nie bzdury, a doświadczenie. Jak mamy juniora i nie mamy wypracowanych standardowych bibliotek czy sposobów i przykładów użycia, to junior wchodzi w kurs z sieci. Tam jest przykład jak użyć. Potem widzę na CR

connection.Open();
var transaction = connection.BeginTransaction();
var command = new Command("select * from demo", connection, transaction))
var reader = command.ExecuteReader();
  while (reader.Read())
 {
	var values = new object[reader.FieldCount];
	reader.GetValues(values);
	Console.WriteLine(string.Join("|", values));
  }

Ofc po co using, czasami widzę taką metodę, gdzie transaction przyleci z parametru etc. Jednak trudniej zrobić sobie krzywdę używając ORM, poza targaniem połowy bazy co łatwo wykryć i naprawić, a gubiące się transakcje to wrzód na tyłku. Już widziałem taki spaghetti, że tylko logami na produkcji śledziło się, co trzeba zrobić, żeby trafić na nie otwartą transakcje, lub gdzie wycofanie idzie źle idzie, bo ofc. nie stosowano UnitOfWork, a transakcje traktowano, jako mechanizm logiki biznesowej. Z ORM trudniej strzelić sobie w stopę i już wolę optymalizować syf w linq, lub dopisać do "repo" czy innego DAO metodę, która zwróci tylko odpowiednie dane, niż śledzić tygodniami transakcje. Zresztą pokaż przykłady tych dobrych bibliotek, co załatwiają, zarządzanie transakcjami, parametrami, mapowaniem danych, konwersją ... i żeby nie można było to nazwać ORM.

4

Zresztą pokaż przykłady tych dobrych bibliotek, co załatwiają, zarządzanie transakcjami, parametrami, mapowaniem danych, konwersją ... i żeby nie można było to nazwać ORM.

Ot choćby Spring JDBC Template? :) Nie ma tam żadnego ORMa, przy odpalaniu query podajesz funkcje które mapuje row na obiekt, transakcje są automagiczne, jest bindowanie nazwanych parametrów, czego chcieć więcej?
ORM na sens w Generic CRUD gdzie chcesz faktycznie wyciągać całe tabele z bazy. W normalnych aplikacjach zwykle jednak cię to nie interesuje.

1

Nie znam tej biblioteki, ale pewnie dlatego,że to ze świata Javy, a ja właśnie siedzę, w .NET ;) Zobaczę na jakiś przykład co to jest. Co do stwierdzenie, że w CRUDach jest sens - no na pewno jest, a jednak większość oprogramowania obecnie to jakiś rodzaj cruda, więc w tym kontekście ORM żyje. Jeśli mamy aplikacje, która serio tylko czasami składuje dane, lub pobiera je z 1-2 tabel i to nie wszystkie to w takim przypadku mógł bym napisać nawet tego sqlcommanda i wyciągnąć dane, ale jeśli wyciąganie danych i wkładanie ich to ponad 50% operacji, wtedy ORM jest niezastąpiony. Jeśli CRUDów jest serio spooooro to twierdzenie, że ORM są w odwrocie jest nadużyciem. Niemniej jak wcześniej wspomniałem, warto znać SQL, właśnie szczególnie jak pisze się w ORM, a poza tym są firmy które programują w stylu lat 80-90 i tam takie coś jak ORM to dziwaczenie ;)

0

Są różne DSLe też które pozwalają na łatwe i przyjemne selecty bez kochania się z różnymi magiami typu dirty checking.
W Springu możesz podpiąć takiego JOOQ pod transakcje Springowe i możesz korzystac z TransactionTemplate (albo jak 99% niestety robi korzystając z @Transactional)

14
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ą.

Oczywiście, że się sprawdzają - jeśli używa się ich rozsądnie i tam, gdzie ma to sens.

Niestety programiści zawsze każdy mechanizm czy narzędzie próbują traktować jako silver bullet i używać go wszędzie, tak jest z interfejsami, testami jednostkowymi, ormami, kontenerami IoC, mockami, mikroserwisami itd. Najpierw ktoś tworzy narzędzie służące do jednego celu, potem to narzędzie obrasta milionem ficzerów pobocznych stając się już tak skomplikowane, że już wszyscy zapominają jaki był jego pierwotny cel, a potem niespodziewanie okazuje się, że utrzymanie takiego narzędzia jest zbyt trudne i kosztowne. No i co należy zrobić? Ogarnąć się i zacząć używać z rozsądkiem tego, co faktycznie ma sens? Oczywiście, że nie! Trzeba znaleźć nowy silver bullet.
I tak się ta branża kręci jak g**no w przeręblu.

0

@somekind: to gdzie ORM mają sens?

4

Jak dla mnie, to wszędzie tam, gdzie nie ma jeszcze bazy danych ale jest potencjalnie rozbudowany persistence model, który będzie się często zmieniał podczas developmentu, a zapis/edycja będą często wykonywanymi operacjami. (Często, nie koniecznie wsadowo, po prostu nie chodzi o rzadko zmienne dane.)

No i generalnie, użycie (bądź nie) ORMa to powinien być szczegół implementacji działania warstwy danych, nie główna decyzja architektoniczna projektu.

4

Ormy to zło wg. mnie. Nieraz musiałem się przy nich nagimnastykować żeby coś wychodzącego po za CRUD zrobić. SQL jest dużo bardziej przyjazny dla mnie - jasno pokazuje intencje a nie piętnaście anotacji definiujących jakieś zachowania albo kilka klas by zrobić SELECT, INSERT, UPDATE lub DELETE.

2

@robertwadowski: nie wiem jakich ORMów używałeś, ale to wygląda na problem z archiekturą. Ani 15 adnotacji, ani klasy inne niż dwie z ORMa i te mapowane na tabele nie są niezbędne.

7

ORM-y są niestety easy to learn, hard to master plus jest niestety ten mismatch (tabelki to jednak nie klasy). Nie zgadzam się jednak, że to czyste zło (równie dobrze OOP to zło, bo w hardwarze nie ma obiektów). Adnotacje porobić każdy potrafi, niestety podstaw związanych ze stanami encji czy first-level cache bardzo brakuje. Tymczasem w 90% można ORM użyć bez bólu i efektywnie. Tylko nie na pałę i nie przy przekombinowanym modelu danych (niepotrzebne kaskady, many-to-many itp). Tutaj z pomocą, aby taki uber-model rozsupłać, przychodzi DDD.

Odnośnie głównego pytania - SQL nie został wyparty przez ORM, doskonale się nadaje do efektywnego odpytywania o agregacje danych czy batchowe operacje na nich, gdzie ORM potrafi puścić maszynę wirtualną z dymem.

0

Własnie w tym problem że łatwo w ORM cos niby napisac, ale jak się nie umie ORM to jest cos bardzo łatwo rozwalić ze względu na dirty checking i wyciekające abstrakcje.

2

Ale wymyślacie problemy. Jak jest problem z wydajnością to piszesz SQL (jeśli nie bardzo się da w ORM) i tyle. A jak nie to sobie piszesz ładny kod w ORM.

0
scibi92 napisał(a):

Własnie w tym problem że łatwo w ORM cos niby napisac, ale jak się nie umie ORM to jest cos bardzo łatwo rozwalić ze względu na dirty checking i wyciekające abstrakcje.

Masz rację, ale z drugiej strony, to w SQL coś łatwo rozwalić np. robiąc zbyt wiele joinów, indeksy na nieodpowiednich kolumnach, albo tworząc blokujące się transakcje. Problem "easy to lern, hard to master" występuje i w tym przypadku.
W ogóle w programowaniu łatwo się rozwala. ;)

1

podejscie SQLowe jest trochę inne i trzeba lekko odrzucić patrzenie obiekt == tabelka. Dzięki temu nie musisz przy każdym requescie wyciągać całego obiektu tylko to co faktycznie potrzebujesz, tak samo z update

1
somekind napisał(a):

Masz rację, ale z drugiej strony, to w SQL coś łatwo rozwalić np. robiąc zbyt wiele joinów, indeksy na nieodpowiednich kolumnach, albo tworząc blokujące się transakcje. Problem "easy to lern, hard to master" występuje i w tym przypadku.

Jak ktoś nie ogarnia czym są relacje, to ORM mu nie pomoże. To tylko warstwa mapująca relacje na obiekty i w drugą stronę. Jak nie wiesz w jaki sposób działa indeks, kiedy i jakiego użyć, to żaden ORM ci w tym nie pomoże.

1

@piotrpo: Taa tylko, że SQL też Ci nie pomoże w takim wypadku :)

0
piotrpo napisał(a):

Jak ktoś nie ogarnia czym są relacje, to ORM mu nie pomoże. To tylko warstwa mapująca relacje na obiekty i w drugą stronę. Jak nie wiesz w jaki sposób działa indeks, kiedy i jakiego użyć, to żaden ORM ci w tym nie pomoże.

Oczywiście, że nie. Ale czy ja coś takiego sugerowałem?

Napisałem tyle, że obie te rzeczy charatketyrzują się niskim progiem wejścia i możliwością strzelenia sobie w stopę jeśli nie rozumie się, co się robi. Wiele razy już poprawiałem SQL pisany przez tych mitycznych specjalistów od baz, którzy się ORM brzydzili, bo niewydajny, a zamiast tego pisali wzajemnie blokujące się transakcje.

0

Skoro ktos nie ogarnia SQL to nie będzie umiał i SQL i ORM. Ja zamierzam wypróbówać w przyszłości JOOQ, czyli coś pośrodku - nie trzeba się męczyć z pisaniem SQLek a nie ma magi JPA :)

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