Czy ORM-y odejdą wkrótce do lamusa?

Stephen Schmidt, znany w środowisku programistów Javy autor bloga Code Monkeyism, postawił bardzo kontrowersyjną tezę, która może nie spodobać się wielu ludziom. Jego zdaniem mapowanie obiektowo-relacyjne (ORM) wkrótce odejdzie do lamusa, po części za sprawą coraz silniejszego ruchu NoSQL.

Jak wiadomo, mapowanie obiektowo-relacyjne to odwzorowanie obiektowej architektury systemu na bazę danych o charakterze relacyjnym. Prowadzi to do powstania wirtualnej obiektowej bazy, do której można uzyskać dostęp z logiki biznesowej aplikacji. Na rynku dostępnych jest wiele gotowych narzędzi do tego – np. Hibernate dla Javy, ADO.NET Entity Framework dla języków Microsoftu, czy SQLAlchemy dla Pythona. Jeszcze na początku wieku, ORM-y niepodzielnie królowały w świecie korporacyjnego oprogramowania. Sam autor kontrowersyjnej tezy o ich zmierzchu wyjaśnia, że jeszcze pod koniec ubiegłego stulecia napisał kilka własnych ORM-ów.

Jednak dzisiaj, zdaniem Schmidta, ORM-y to ułuda. Ich celem miało być szybkie tworzenie aplikacji i uniknięcie pisania wielokrotnie powtarzalnego kodu. Jednak przynoszą one problemy, które stają się znacznie większe, niż te korzyści.

Wydajność

Główny problem to wydajność – nikt nie chce zaglądać do logów Hibernate SQL z tego powodu, pisze Schmidt, ponieważ gdyby zobaczyć na własne oczy kwerendy przez ten ORM generowane, to mogłoby się to źle skończyć. Jak napisał niedawno na swoim blogu hatful of hollows niejaki Aldo z Nowej Zelandii, głównym powodem dla którego się korzysta z ORM-ów, jest magiczna fraza „niezgodność impedancji” (ang. impedancy mismatch), za co winę ponosi sama koncepcja języka zapytań, zakładająca brak algorytmicznej uniwersalności. Jednak czy takie magiczne myślenie ma sens?

Aldo pisze, że zależy to od tego, w jaki sposób i jak często „abstrakcje nawalają” – a w wypadku ORM-ów dzieje się to nader często. Można wykorzystać ORM-a i myśleć na poziomie obiektowym, ale kiedy trzeba zrobić cokolwiek bardziej skomplikowanego, np. zoptymalizować kwerendę, „znów jesteśmy w krainie tabel i kluczy zewnętrznych”. ORM-y nie rozwiązują problemu niezgodności impedancji, lecz tylko go odsuwają w czasie.

«poprzednia 1 2 następna »

Podoba Ci się ten tekst? Powiedz o tym innym na Fb: lub na G+:

publikuj:

wydrukuj

17 skomentuj »

Polecamy

Reklama

Komentarze

#1 mikimoto 2009-10-18 18:16:55 0
Od dluzszego czasu powtarzam ze ORMy to zlo, fajnie sie pisze z ich wykorzystaniem aplikacje typu prosty sklep internetowy ale cos co wymaga wiecej wydajnosci i bardziej skomplikowanych zapytan po prostu jest zbyt skomplikowane aby optymalnie zrobic to w ORM jesli w ogole mozliwe.
IP: 95.108.33.[...] Opera/9.80 (X11; Linux i686; U; en) Presto/2.2.15 Version/10.00
#2 karion 2009-10-19 08:29:51 0
Bo prawda jest taka że zapominamy o cyklu rozwoju aplikacji. Wszystkie promowane aktualnie metody prowadzenia rojektu ciagle powtarzają "szybciej koduj". I tu ORM si sprawdza. Ale potem, gdy program działa, trzeba po prostu siaść i go zoptymalizować. W szczególności zapytania SQL, a ORM zostawic w komentarzach by zespół od utrzymania kodu lepiej rozumiał. Bo ORM jest zdecydowanie czyteliejsze, ale większość produktów w końcu się upomni o wydajność.
IP: 77.253.214.[...] Mozilla/5.0 (Windows; U; Windows NT 5.1; pl; rv:1.8.1.14) Gecko/20080404 Firefox/2.0.0.14 (.NET CLR 3.5.30729)
#3 leszlo 2009-10-19 13:05:33 0
A może problemem jest architektura? W architekturze frameworkow królują

Active Record i Table Mapping do których ORM-y idealnie pasują. A może

Data Mapper i pisanie zapytań samemu

rozwiązałoby problemy wielu programistów? Niestety w naszej profesji lenistwo króluje :)
IP: 83.14.144.[...] Mozilla/5.0 (X11; U; Linux i686; pl-PL; rv:1.9.0.14) Gecko/2009090216 Ubuntu/9.04 (jaunty) Firefox/3.0.14
#4 Pablo77 2009-10-19 14:57:18 0
Hej,

Jako PHP developer musze powiedziec ze my PHP-owcy jeszcze mamy jedna sekretna bron czyli DQL z pakietu Doctrine!

Oczywiscie nie zalatwia ona wszystkich problemow ale jednoczesnie nie "odsuwa ich w czasie".

Dzieki DQL-owi dokładnie kontrolujesz zapytania jednoczesnie nie zastanawiajac sie nad JOIN-ami. Ponadto skladnia DQL-a jest mocno uproszczona' wersja SQL-a, czyli jak ja to nazywam hassle-free SQL!

Jak zapomnisz o cos zapytac w DQL query to Doctrine sama to sobie znajdzie i dociagnie!

Polecam goraco wszystkim ktorzy maja obawy przed ORM-ami a wciaz uzywaja SQL-a.

Pozdrawiam!

P
IP: 81.139.189.[...] Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.9.0.14) Gecko/2009090216 Ubuntu/9.04 (jaunty) Firefox/3.0.14
#5 nigras 2009-10-19 20:31:21 -1
Teza trochę może kontrowersyjna, ale przyznam rację autorowi. Moim zdaniem to ORM-y jak najbardziej na początku kodowania, ale dobrze ukryte za interfejsami. Później do stopniowej wymiany - ale tam gdzie jest taka potrzeba. Bardzo dobrze sprawdza się tutaj spring framework. Zmiana dao opartego o hibernate na to oparte o wspomniane spring-jdbc może następować stopniowo, we fragmentach aplikacji, bez narażania na zmiany reguł transakcyjności.

Sporym nieporozumieniem jest użeranie się z niuansami hibernate przy aplikacjach gdzie jako UI mamy GWT - znane problemy z konwersją do JS PersistentBag i PersistentSet, inaczej dla pustych, inaczej dla lazy i eager.

ORM powoduje też, że zwykle mamy zawsze cały dostępny obiekt, a często potrzebujemy jakis podzbiór danych. Przesyłanie i przetrzymywanie po stronie przeglądarki zbyt dużej ilości danych jest jedną z przyczyn powolnego działania aplikacji w GWT.

Pozdrawiam Pokaż komentarz
IP: 194.106.193.[...] Mozilla/5.0 (X11; U; Linux i686; pl-PL; rv:1.9.0.14) Gecko/2009090216 Ubuntu/9.04 (jaunty) Firefox/3.0.14
#6 Jan Koprowski^® 2009-10-20 07:53:31 -1
Ja w temacie jestem nowicjuszem. Więc może mi ktoś wyjaśni. Z mojego punktu widzenia ORM to "czytelność wzamian za wydajność" no i spełniają swoje zadanie. Tutaj powinna rosnąć wydajność bazy danych a nie ORMów!

A jak ktoś potrzebuje wydajności to ...czemu miałby nie robić zapytań SQLowych z dobrymi komentarzami? Ale same zapytania nie są już tak czytelne jak ORMowe łańcuszki. Prawda?

Moim zdaniem jest to manipulowanie faktami na własną korzyść. Bo ORMy czarują - ale wiadomo w jakim celu i co za to dostajemy.

Mi zawsze przyszłością zdawały się obiektowe bazy danych. Z wielką nadzieją patrzę na Apache CouchDB i to ona moim zdaniem podbije rynek:) Pokaż komentarz
IP: 89.79.56.[...] Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US) AppleWebKit/532.0 (KHTML, like Gecko) Chrome/3.0.195.27 Safari/532.0
#7 Holden Caulfield^® 2009-10-20 10:41:08 0

@Jan Koprowski"A jak ktoś potrzebuje wydajności to ...czemu miałby nie robić zapytań SQLowych z dobrymi komentarzami? Ale same zapytania nie są już tak czytelne jak ORMowe łańcuszki. Prawda?"
Jak dla kogo. Dla mnie odpowiednio sformatowane zapytania SQL są bardziej czytelne niż ORMowa sieczka.
IP: 83.6.8.[...] Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/532.2 (KHTML, like Gecko) Chrome/4.0.222.12 Safari/532.2
#8 Gff 2009-10-20 13:39:11 0
@Pablo77

Widać nie do końca rozumiesz tematu. Doctrine jest jak najbardziej typowym ORMem wzorowanym na Hibernacie; wszystkie wady ORMów opisywane w tym artykułe tyczą się również i jego.

A jeżeli chodzi o głos w sprawie samego ORM to uważam, że dopóki nie powstawie sensowna alternatywa dla relacyjnych baz danych (NoSQL go!:), ORM jest najsensowniejszym sposobem dostępu do bazy relacyjnej z poziomu kodu obiektowego dla aplikacji w której prędkośc działania nie jest kluczowa.

Nie rozumiem również problemu z optymalizacją zapytać, natomiast jeżeli potrzeba skorzystać ze stricte specyficznych cech bazy w Hibernacie żawsze można skorzystać z zapytania SQL.
IP: 194.146.120.[...] Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9) Gecko/2008052906 Firefox/3.0
#9 MJS 2009-10-21 09:11:22 1
A ja już myślałem, że zapowiada się zmierzch jedenj z najfajniejszych technologii jakie dostępne są w Javie.

Jeśli problemem Hibernate'a jest wydajność, to może trzeba poprawić wydajność? A być może (uwaga, teza kontrowersyjna) stworzyć wersje pod poszczególne bazy danych, lepiej zoptymalizowane? I tak z tą przenośnością to przesada.

Poczytałem trochę na temat NoSQL i okazuje się, że jest to dobre w

małych projektach i nawet nikomu się nie śni że, prześcignie Oracla,

jeśli mamy do czynienia z dużą ilością danych.

Jak dla mnie NoSQL może i jest ciekawym rozwiązaniem, ale zupełnie niepraktycznym i nie zanosi się, żeby stało się dominującym standardem w najbliżej i trochę dalszej przyszłości.
IP: 78.8.126.[...] Mozilla/5.0 (X11; U; Linux i686; pl; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3
#10 Pablo77 2009-10-21 10:55:51 0
Gff

Hmm, wydaje mi sie jednak ze Doctrine w porownaniu z Propelem czy innymi Active Record jest nieco inny, a juz na pewno bardziej elastyczny! Nie chce go oczywiscie gloryfikowac bo kazdy system ma swoje wady ale zrozum ze to o czym pisze to inne podejscie do tworzenia kwerend a nie sposobu przechowywania danych!

Jezeli wytniesz ze wszystkich zapytan SQL relacje pomiedzy tabelami i umiescisz je w jednym konkretnym miejscu to uzyskujesz calkiem zwinna arhitektore. Po prostu wybierasz precyzyjnie dane (konkretne atrybuty) w ilosci dokladnie takiej jaka potrzebujesz a jednoczesnie qwerenda jest zoptymalizowana pod katem nakladu pracy!

Wieze rowniez iz przetestowales juz rozwiazania typu NoSQL i znasz ich niepomijalne ograniczenia co do ilosci mozliwych wdrozen.

Osobiscie jestem szeroko otwarty na nowe - nierelacyjne rozwiazania i ciesze sie ze tacy ludzie jak Stephen Schmidt staraja sie naglosnic ewolucje w systemach przechowywania danych!

Pozdrawiam

Pablo
IP: 87.194.64.[...] Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.9.0.14) Gecko/2009090216 Ubuntu/9.04 (jaunty) Firefox/3.0.14
#11 Gff 2009-10-25 20:09:42 0
@Pablo77

Dalej twierdze, że nie rozumiesz zbytnio tematu jakim sa ORMy. Ponawiam swoją tezę, iż Doctrine jest zwykłym standardowym ORMem wzorowanym na bodajże najpolularniejszym obecnie rozwiązaniu tego typu czyli Hibernacie.

Twoim kluczowym argumentem jest język zapytań, umożliwiający pobieranie danych na poziomie modelu obiektowego, jednak rozwiązanie to nie jest niczym szczególnym, chyba że opiszesz mi wyrażne różnice pomiędzy DQLem a HQL'em (z Hibernate'a) lub EJB QLem z JPA.

Nawet omijając możliwe różnice, kwestią problemową stanowi sam proces zamiany zapytań na SQLa, który stanowi sedno problemu rozwiązan ORM.

Co więcje śmiem twierdzić, iż DQL zapewne nie jest w tej kwestii wydajniejszy, biorąc pod uwagę biznesowe zainteresowanie (a tym samym nacisk jaki położony jest na wydajność) Hibernatem.

Wniosek: Jakkolwiek DQL nie jest wspaniały :) tyczą go te same problemy co innych ORM w momencie przetwarzania zapytań na SQLa i operacji na danych w bazie.

I przy okazji, żeby nie było wątpliwości. Uważam, iż ORM w tym momencie jest najlepszym rozwiązaniem problemu niezgodności paradygmatów OR (i nikt mi nie wmówi że takiego problemu nie ma), a kwestię wydajnościowe zawsze można jakoś rozwiązać!
IP: 79.110.195.[...] Mozilla/5.0 (Windows; U; Windows NT 6.0; pl; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3 (.NET CLR 3.5.30729)
#12 Gff 2009-10-25 20:11:04 0
Ehh pisząc "Jakkolwiek DQL nie jest wspaniały" miałem na myśli "Jakkolwiek DQL jest wspaniały".. ;)
IP: 79.110.195.[...] Mozilla/5.0 (Windows; U; Windows NT 6.0; pl; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3 (.NET CLR 3.5.30729)
#13 Pablo77 2009-10-27 10:37:03 0
Gff

Ciesze sie ze wyciagasz rzeczowe argumenty w tej dyskusji.

Wielu programistow staraloby sie po prostu uprzec na swoim i zamknac na zewnetrzene sugestie! Dodatkowo pewnie probowali by grac w zalosne wojenki jezykowe probujac za wszelka cene upokorzyc przeciwnika; czego ja, i jak przypuszczam Ty, fanem nie jestesmy.

Ciesze sie rowniez, ze zrozumiales moj pierwszy komentarz i tak rzeczowo na niego odpowiedziales. Kolejna optymistyczna kwestia to to, iz zaden z nas nie poruszyl kwestii Rubiego ktory, bez warstwy cache, wg testow potrafi byc jeszcze wolniejszy od Javy.

Mam jeszcze jedna dobra wiadomosc, jako freelancer w Londynie nie narzekam na ilosc pracy i zarobki z wykorzystaniem DQL-a.

Pozdrawiam

Pablo
IP: 87.194.64.[...] Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.9.0.14) Gecko/2009090216 Ubuntu/9.04 (jaunty) Firefox/3.0.14
#14 hipertracker^® 2009-10-30 03:12:27 1
Po pierwsze, ORM'y są do dupy dlatego, że RDBMS są do dupy. Bazy relacyjne są anachronizme. Są wolne (zdychają przy joinach na większym zbiorze rekodów) i zbyt prymitywne do modelowania bardziej złożonych scenariuszy. Największe bazy to bazy obiektowe (choćby smalltalkowy Gemstone).

Inna sprawa, że bazy obiektowe są, z konieczności, ściśle związane z danym językiem (lub platformą, bo nie musi to być koniecznie ten sam język, np. obiekty Scali i Clojure są kompilowane do obiektów Javy i integrują się przezroczyście z resztą kodu Javy; obiekty mającego wyjść JRuby 1.5 też mają być obiektami Javy, trwają nad tym prace).

Z kolei bazy obiektowe takiej jak Gemstone są właściwie jedną wielką, rozproszoną i transakcyjną pamięcią trwałą (trwają prace nad Maglev - Gemstone dla Ruby). Java ma coś podobnego - Terracotę.

Ale najciekawszym i najbardziej nowoczesnym podejściem są, moim zdaniem, bazy grafowe. Np. świetny Neo4j (zobacz prezentację: http://www.infoq.com/presentations/emil-eifrem-neo4j). Symetryczne i asymetryczne grafy dużo lepiej nadają się do budowania skomplikowanych zależności między różnymi funkcjonalnymi modułami nowoczesnej webowej. Dlatego sądzę że poza bazami obiektowymi, przyszłość należy do baz grafowych.
IP: 78.16.205.[...] Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; pl; rv:1.9.1.4) Gecko/20091016 Firefox/3.5.4
#15 hipertracker^® 2009-10-30 03:20:55 0
Pablo77: co to znaczy "jeszcze wolniejszy"? :) Przecież Java jest wielokrotnie szybsza nie tylko od Ruby'ego ale każdego innego języka z dynamiczną typizacją. (Najszybszym językiem z dynamiczną typizacją jest Clojure) Java dzięki dynamicznej komilacji Hotspota jest często wyraźnie szybsza od C++. Ruby oczywiście jest wolniejszy ale jest też dużo bardziej skomplikowany i pozwala na takie cuda z dynamiką jakie Javie się nie śniły. Coś za coś. Co do szybkości to Ruby 1.9 jest wyraźnie szybszy Pythona który z kolei jest wyraźnie szybszy od PHP (teraz PHP to nie tylko jeden z najbardziej chaotycznych ale także najwolniejszych języków) A jeszcze szybszy jest JRuby który przyśpiesza z wersji na wersję.
IP: 78.16.205.[...] Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; pl; rv:1.9.1.4) Gecko/20091016 Firefox/3.5.4
#16 AdamB 2009-10-30 09:56:51 0
Problem z tymy fajnymi bazami danych (obiektowe, grafowe, dokumentowe, itd) jest taki, że nie mają SQL . Model relacyjny jest jaki jest, ale SQL jako ustandaryzowany, popularny, deklaratywny język zapytań jest świetny. Potwierdzi to każdy kto wolał napisać DQL/HQL zamiast męczyć się ze składaniem obiektowych zapytań.

Bez takigo narzędzia budowanie warstwy komunikacji z baza danych jest dużo trudniejsze (polecam końcówkę artykułu o Cassandrze w Diggu). OQL nie jest gotowy, nie ma też dojrzałej implementacji. Co do reszty to nic nie słyszałem o podobnym narzędziu.

Nadzieję upatruję w modelu danych RDF i języku SPARQL. Są to narzędzia wywodzące się z technologii semantycznych, ale RDF całkiem nieźle nadaje się do modelowania obiektów.
IP: 87.206.165.[...] Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.3) Gecko/20090910 Ubuntu/9.04 (jaunty) Shiretoko/3.5.3
#17 hipertracker^® 2009-10-30 12:00:29 1
AdamB, widzę że nii możesz wyrwać się z myślenia w kategorii płaskich tabel i ewentualnie ORM'a. Jak napisałem wcześniej, bazy relacyjne to technologia przestarzała, anachroniczna. A skoro RDBMS to syf, to syfem będzie też SQL, bo to tylko warstwa abstrakcji dostępu do RDBMS, nic więcej.

Na dodatek SQL to nie jest żaden standard. Jest wiele dialektów i nie ma bazy która by nie rozszerzała standardowego SQL'a o swoje rozszerzenia. Każda baza ma swój dialekt SQL'a który nie jest w pełni kompatybilny z innymi. W efekcie jak chcesz coś naprawdę zoptymalizować, to musisz sięgać do tych nietypowych, specyficznych dla danej bazy konstrukcji. Ta część jest więc nieprzenośnia i SQL w tym wypadku ma ten sam problem co ORM. Ale po co w ogóle SQL? Po co myślenie w ograniczonych kategoriach płaskich tabel? To może było dobre w latach 70-tych ale dziś to jest już zdecydowanie przestarzałe i ograniczające.

Co do bazy obiektowej, to nie musisz tam składać żadnych zapytań. Po prostu pracujesz z obiektami nie matwiąc się o trwałość danych. Bardziej naturalnie chyba się nie da.
IP: 89.167.220.[...] Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.4) Gecko/20091016 Firefox/3.5.4

Aby dodać komentarz, musisz podać swój nick, treść komentarza oraz poprawnie przepisać oba słowa z obrazka (słowa muszą być rozdzielone spacją).
W treści komentarza można używać języka formatowania BBcode.