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-03 09:29
5

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.


Masz problem? Pisz na forum, nie do mnie. Nie masz problemów? Kup komputer...
edytowany 1x, ostatnio: Shalom, 2019-12-03 09:30

Pozostało 580 znaków

2019-12-03 10:51
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.

Pozostało 580 znaków

2019-12-03 11:34
2

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.


Masz problem? Pisz na forum, nie do mnie. Nie masz problemów? Kup komputer...
edytowany 1x, ostatnio: Shalom, 2019-12-03 11:35

Pozostało 580 znaków

2019-12-03 12:08
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 ;)

Opis tego Spring JDBC brzmi trochę jak Dapper w świecie .NET. - Ktos 2019-12-03 20:56
Tylko, że Dapper ma w poważaniu transakcje i to już gestia programisty, chyba, że coś się pozmieniało od czasów jak tego używałem? - somedev 2019-12-03 21:01
Chyba niestety nie, o transakcje trzeba dbać samemu :/ - Ktos 2019-12-03 21:03

Pozostało 580 znaków

2019-12-03 12:34
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)


Nie pomagam przez PM. Pytania zadaje się na forum.
Możesz wyjaśnić dlaczego używanie @Transactional jest złe? - Skoq 2019-12-03 15:25
Czemu pisac Transactional które sie nie komponuje, jak możesz użyć zwykłych lambd do transakcji? Jak masz transactional i cache, to najpierw zrobi się transakcja i później cache, czy najpierw cache a później transakcja - scibi92 2019-12-03 15:44
Nie będę zgadywał ;P Mógłbyś zarzucić jakimś linkiem do poczytania bądź co powinienem wygooglować aby coś ciekawego na ten temat znaleźć? :) - Skoq 2019-12-03 16:12

Pozostało 580 znaków

2019-12-03 13:26
12
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ówno w przeręblu.


"HUMAN BEINGS MAKE LIFE SO INTERESTING. DO YOU KNOW, THAT IN A UNIVERSE SO FULL OF WONDERS, THEY HAVE MANAGED TO INVENT BOREDOM."
edytowany 2x, ostatnio: somekind, 2019-12-03 13:27
"programiści zawsze każdy mechanizm czy narzędzie próbują traktować jako silver bullet i używać go wszędzie" - to chyba powinno być motto 4programmers :D - wartek01 2019-12-03 15:32

Pozostało 580 znaków

2019-12-03 14:17
0

@somekind: to gdzie ORM mają sens?


Nie pomagam przez PM. Pytania zadaje się na forum.

Pozostało 580 znaków

2019-12-03 14:51
3

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.


"HUMAN BEINGS MAKE LIFE SO INTERESTING. DO YOU KNOW, THAT IN A UNIVERSE SO FULL OF WONDERS, THEY HAVE MANAGED TO INVENT BOREDOM."
chodzi Ci o tworzenie bazy przy pomocy ORM? - Miang 2019-12-03 14:55
Jak masz stara bazę to wprowadzenie orm i migracji jest często trudne. Tworząc bazę z głowa pod orm od początku jest łatwiej. Jeszcze lepiej code first i migrować. - somedev 2019-12-03 15:06
@Miang: owszem. @somedev: zgadza się, dlatego napisałem - "tam, gdzie jeszcze nie ma bazy". - somekind 2019-12-03 15:27
@somekind: jasne, bardziej pisałem do @Miang i zapomniałem @ dać. - somedev 2019-12-03 15:34

Pozostało 580 znaków

2019-12-03 15:09
1

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.

Pozostało 580 znaków

2019-12-03 15:26
1

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


"HUMAN BEINGS MAKE LIFE SO INTERESTING. DO YOU KNOW, THAT IN A UNIVERSE SO FULL OF WONDERS, THEY HAVE MANAGED TO INVENT BOREDOM."
architektura to problem był sam w sobie, jeśli chodzi o ormy to był hibernate i być może był przekombinowany - nie mam w tym wielkiego doświadczenia, annotacji i klas było jak dla mnie za dużo. - robertwadowski 2019-12-04 09:42
Ale to jest to, o czym pisałem wcześniej - problem z prawidłowym użyciem narzędzia, nie problem z narzędziem. - somekind 2019-12-04 12:02

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)