Czy SQL został wyparty przez ORM'y?

0

ORMy nigdy nie wyprą, bo służą tylko do specyficznej części pracy z bazami danych (sam zresztą nie jestem programistą, a z baz korzystam, więc jak mógłbym używać ORMów?).
Tak, można być programistą specjalizującym się tylko w bazach danych. Co więcej, można na tym zarobić często pieniążki lepsze niż w innych działkach programowania, tyle że zanim się za to zabierzesz to musisz wiedzieć, że raczej małe masz szanse na typową deweloperkę. Bazy danych na ogół to bardzo specyficzna działka i praca z nimi nie wygląda tak jak klepanie CRUDów w Spring Boocie.

1

Ciekawe spojrzenie. Niemniej nie uważam, że trzeba robić tak jak gość pokazał i znów pisać SQL w klasach modelu, bo można użyć do tego ORM, Dappera czy Automappera pod spodem. Inaczej programowanie staje się znów pracowite, Z drugiej strony nie przekonuje mnie to, że tworząc DTO/POCO robimy głupie obiekty, gość chyba za bardzo zafiksował się na enkapsulacji i zapomniał o SRP. Co sądzicie? @somekind - koło 30 minuty, zaczął podobnie gadać o repozytoriach, co Ty - czy Tobie właśnie mniej więcej o to chodzi? Tak, znam Twoje wpisy na blogu, ale warto uściślić.

5

Obejrzałem tylko fragment, generalnie nie podoba mi się wciskane OOP na siłę. Ja nie widze problemu z korzystaniem z klas typu model/DTO itp czyli pojemników na dane. I tak, jak masz instacje

data class Person (val firstName: String, val lastName: String)

to nie masz tak naprawde enkapsulacji, ale tam jej nie potrzebujesz. To nie jest klasa odpowiedzialana za pule wątków, ani obsługłę kolejek ani pobieranie plików z neta.

1

@somedev: to jest Yegor, on mówi dziwne rzeczy już od lat, i na forum już miewaliśmy dyskusje o jego poglądach, w nich też się wypowiadałem:
Getery i setery to zło, immutable ponad wszystko, ORMy wielką pomyłką
Wideo z rantem na ORMy. Kto z was podniósł rękę?

1

Szkalowanie ORMów jest tak stare jak same ORMy.

0

ORM-y są przede wszystkim dla wygody programisty i w tych kategoriach należałoby to rozpatrywać. Query Buildery tak samo. Zamiast zabaw na RAW SQL zależy od implementacji i konkretnego frameworka to nie dość że można obsłużyć np. walidację danych (i obsługę wyjątków typu ORM Validation Exception) to jeszcze automatyczne filtrowanie czy konwersję danych. Proste w implementacji działania na CRUD-ach, przejrzyste i łatwe do zrozumienia kody. Jeśli ktoś uwielbia bawić się na surowych poleceniach SQL, zwłaszcza na modelach typu Nested Set, EAV czy innych tego typu bez obaw o błędy w kodzie to w sumie nie ma żadnego problemu, podobnie jak surowe polecenia vs Query Buildery, no ale dla innych programistów to kwestia odpowiedniej wygody.

0

Kwestia wygody, ale i efektywności, a czas to pieniążki.

1

ORM można sobie wykorzystywać w jakimś niedużym projekcie / MVP. Nie widzę tego w większych projektach z naciskiem na wydajność, bo te generują często spory narzut dla każdego zapytania. Przykład dla kilku różnych ORM Golang vs Raw (nie pamiętam na jakiej wersji Go przeprowadzony):

10000 times - MultiInsert 100 row

raw:         12.67s      1266673 ns/op  110805 B/op    811 allocs/op
orm:         15.60s      1559779 ns/op  147207 B/op   1534 allocs/op
xorm:        17.21s      1720575 ns/op  234011 B/op   4751 allocs/op
qbs:         Not support multi insert
gorm:        Not support multi insert
hood:        Not support multi insert
gorp:        Not support multi insert
upper.io:    Not support multi insert
modl:        Not support multi insert

40000 times - Insert

raw:          5.50s       137549 ns/op     552 B/op     12 allocs/op
qbs:          6.00s       149933 ns/op    5515 B/op    106 allocs/op
modl:         7.95s       198630 ns/op    1312 B/op     28 allocs/op
xorm:         8.67s       216816 ns/op    2537 B/op     68 allocs/op
orm:          9.08s       226914 ns/op    1937 B/op     40 allocs/op
gorp:        10.15s       253762 ns/op    1384 B/op     29 allocs/op
hood:        11.39s       284721 ns/op   12511 B/op    299 allocs/op
upper.io:    12.42s       310613 ns/op   12562 B/op    450 allocs/op
gorm:        14.22s       355437 ns/op    7999 B/op    136 allocs/op

40000 times - Update

raw:            6.13s        153190 ns/op     616 B/op     14 allocs/op
qbs:            6.20s        154884 ns/op    5515 B/op    106 allocs/op
upper.io:       8.60s        214909 ns/op   13728 B/op    453 allocs/op
xorm:           9.04s        225945 ns/op    2801 B/op     96 allocs/op
orm:            9.65s        241360 ns/op    1929 B/op     40 allocs/op
modl:          10.43s        260855 ns/op    1488 B/op     36 allocs/op
gorp:          10.67s        266751 ns/op    1536 B/op     35 allocs/op
hood:          11.78s        294398 ns/op   12511 B/op    299 allocs/op
gorm:          26.05s        651201 ns/op   20794 B/op    369 allocs/op

80000 times - Read

raw:           6.58s        82266 ns/op    1529 B/op     40 allocs/op
qbs:           7.03s        87909 ns/op    8072 B/op    180 allocs/op
modl:         13.83s       172883 ns/op    1968 B/op     48 allocs/op
hood:         14.38s       179738 ns/op    4482 B/op     93 allocs/op
orm:          14.55s       181900 ns/op    2898 B/op    100 allocs/op
gorp:         15.30s       191308 ns/op    1968 B/op     55 allocs/op
xorm:         16.47s       205898 ns/op    9408 B/op    247 allocs/op
gorm:         18.51s       231380 ns/op   12767 B/op    219 allocs/op
upper.io:     24.65s       308077 ns/op   31601 B/op    775 allocs/op

40000 times - MultiRead limit 100

raw:          10.44s       260979 ns/op     34897 B/op   1324 allocs/op
modl:         16.92s       422899 ns/op     50058 B/op   1734 allocs/op
gorp:         20.50s       512606 ns/op     66071 B/op   2066 allocs/op
orm:          26.58s       664411 ns/op     85324 B/op   4291 allocs/op
qbs:          26.71s       667770 ns/op    205461 B/op   6433 allocs/op
hood:         44.07s      1101719 ns/op    235951 B/op   9612 allocs/op
xorm:         51.03s      1275847 ns/op    180246 B/op   8187 allocs/op
gorm:         52.34s      1308521 ns/op    292381 B/op   6610 allocs/op
upper.io:    321.14s      8028406 ns/op   2878946 B/op  71178 allocs/op

Wiem, że wielu będzie negować takie testy ale trudno. Jakiś punkt odniesienia trzeba mieć (bez faworyzowania).

8

Jeśli ktoś nie rozumie, do czego służą ORMy, to zawsze może przedstawić test , który ukazuje, że ORMy nie służą do tego, do czego nie służą.
W napięciu oczekuję na dowód na to, że fiat 126p nie nadaje się do dostarczania kruszywa przy budowie autostrady.

Pokaż wyższość braku ORM nad ORM dla aplikacji, które mają 1000 insertów na minutę.

1
axde napisał(a):

ORM można (...)
Wiem, że wielu będzie negować takie testy ale trudno. Jakiś punkt odniesienia trzeba mieć (bez faworyzowania).

wygląda tak samo jak porównanie kontenerów IoC do new, można, będzie szybciej ale to tylko test syntetyczny na przypadku który nigdy nie będzie miał miejsca w aplikacji biznesowej

0

Pokaż wyższość braku ORM nad ORM dla aplikacji, które mają 1000 insertów na minutę.

Brak orania refleksją i dirty checkingu.

0

@scibi92: W refleksji nie ma nic złego, jeśli język język/technologia ją rzeczywiście wspiera, a dirty checking jest opcją. Pokaż na liczbach, nie na mechanizmach.

1

@axde

ORM można sobie wykorzystywać w jakimś niedużym projekcie / MVP.

Stackoverflow rank #37 używa EF Cora + Dappera

0

Nie da się tego pokazać "w liczbach". Być może w niektórych ORMach dirty checking jest opcją, wiem że w JPA nie jest i to nie raz dawało się w kość.
Osobiście np. wolałbym pracę z jakąs DSL-ową biblioteką jak JOOQ która nie wymaga boilerplate kodu a elimunuje wady ORMów

5

@scibi92: no nie da się pokazać w liczbach, bo przy takim wolumenie ORM nie jest wolniejszy niż czysty SQL w sposób zauważalny dla użytkownika aplikacji.

ORMy mają zasadniczo trzy wady:

  1. Trzeba przeczytać instrukcję, robienie na pałę się źle kończy we wszystkim, co nie jest MVP (a i w MVP czasem też);
  2. Trzeba zrozumieć, kiedy jest sens ich używać, i mieć do rozwiązania problem możliwy do rozwiązania przy ich pomocy.
  3. Trzeba myśleć przy ich używaniu.

Są alternatywne narzędzia, pewnie nawet łatwiejsze w użyciu i szybsze w pewnych aspektach, ale jak znam życie, to już ktoś gdzieś robi benchmark porównujący z czystym sql pisanym w asemblerze, a ktoś inny gdzieś potrzebuje zrobić coś, czego się nie da, i zaraz zacznie winić i hejtować to narzędzie. Więc nie wiem, czy warto się przywiązywać.

1

Niestety nie rozumiesz za bardzo o co mi chodzi. Mi nie chodzi o wydajność(aplikacji) , a o czytelność kodu, łatwość debugowania i podobne rzeczy.

0

@scibi92: cytowałeś mój wpis, w którym mi chodziło o wydajność, bo taki argument został tu podniesiony wcześniej. Tak więc założyłem, że chodzi Ci o wydajność, bo jeśli nie, to po co byś mnie cytował?

Czytelności kodu i łatwość debugowania to już kwestie konkretnych ORMów, nie można tego używać jako argumentu przeciwko ORMom jako grupie. Ja jakoś nie miałem nigdy problemów z czytelnością ani debugowaniem, problemy zaczynały się dopiero, gdy ktoś przesadzał z czarnoksięstwem i próbował zrzucić na ORM coś spoza zakresu jego przydatności, bo "przecież da się".

4
axde napisał(a):

ORM można sobie wykorzystywać w jakimś niedużym projekcie / MVP. Nie widzę tego w większych projektach z naciskiem na wydajność, bo te generują często spory narzut dla każdego zapytania.

  1. ORM mają narzut, niektóre jednak przy odpowiedniej konfiguracji dosyć mały.
  2. Przy projektach z naciskiem na wydajność stosuje się zazwyczaj różnego rodzaju optymalizacje, które np. ograniczają ilość zapytań do bazy na rzecz cache'owania
  3. Narzut generowany przez ORM jest czasem o wiele mniejszy niż to co generują sami programiści
  4. Większe projekty... Tu już widziałem niestety cuda. Przyjdzie jeden z drugim i narzeka, że ORM jest do bani. Narzucają więc klepanie SQL a potem zmieniają pracę/projekt. Przychodzi ktoś nowy i dochodzi do wniosku, że te SQL to wcale nie są takie krytyczne dla systemu i jemu nie chce się ciągle pisać/składać zapytań więc optymalizuję sobie pracę implementując... własny ORM (a przynajmniej namiastkę :D).

Moim zdaniem na wszystko jest miejsce. I na ORM i na SQL, można te rzeczy ze sobą łączyć i np wykonywać procedury składowane przy użyciu ORM jeśli przynosi to realne korzyści.
SQL nie został wyparty, ponieważ mimo tego że ORM jest jakąś abstrakcją na bazę to ona jednak cieknie, czasem trzeba odpowiednio skonstruować zapytanie żeby nie zarżnąć bazy danych.

Brak orania refleksją

Hejt na refleksję to taka sama zaraza jak forsowanie weganizmu albo nawet scrum :D

0

Moim zdaniem na wszystko jest miejsce. I na ORM i na SQL, można te rzeczy ze sobą łączyć i np wykonywać procedury składowane przy użyciu ORM jeśli przynosi to realne korzyści.

No tak bo istnieje albo jakiś goły SQL + niskopoziomowa bibioteka jak JDBC albo ORM. Nie ma innych alternatyw ;]

Hejt na refleksję to taka sama zaraza jak forsowanie weganizmu

Akurat to całkiem dobre porównanie, bo ludzie w Polsce jedzą zdecydowanie za dużo mięsa (na śnadanie, obiad i kolacje dosyć czesto) gdzie powinno się jeść na ogół z 3-4 razy w tygodniu.
Podobnie jak z nadużywaniem refleksji przez programistów

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