Jakie są zalety korzystania z abstrakcji bazy danych przez ORM? [Zamknięte]

19

Zaczynam korzystać z ORM zalecanego przez wybrany przeze mnie framework i chociaż podoba mi się pomysł dodania warstwy abstrakcji zapewnianej przez ORM, zaczynam rozumieć, co to naprawdę oznacza. Oznacza to, że nie pracuję już z moją bazą danych (mysql), a wszelkie funkcje specyficzne dla mysql zniknęły za oknem, jakby nie istniały.

Idea ORM polega na tym, że stara się mi pomóc, czyniąc bazę danych agnostyczną. Brzmi świetnie, ale często nie jest to powód, dla którego wybrałem system konkretnej bazy danych. Ale idąc trasą agnostyczną bazy danych, ORM przyjmuje najniższy wspólny mianownik, co oznacza, że ​​otrzymuję najmniejszy zestaw funkcji (obsługiwanych przez wszystkie bazy danych).

Co zrobić, jeśli wiem, że na dłuższą metę nie będzie przełączenie podstawowej bazy danych? Dlaczego nie uzyskać dostęp do funkcji specyficznych dla bazy danych, zbyt?

jblue
źródło
2
+1: bardzo interesujące. Generalnie byłem zwolennikiem ORM, ale zwykle uważałem RDBMS za równe (co ostatnio zacząłem postrzegać jako błędne).
Steven Evers
Brzmi to jak chcesz tylko potwierdzenie swojej własnej opinii; blog może dla ciebie lepiej niż strona Q & A.
Prawdopodobnie nie powinieneś potrzebować niczego więcej niż zapewnia ORM. Po prostu chcesz przechowywać dane obiektu w bazie danych i właśnie to zrobi ORM. Nie powinieneś potrzebować żadnych innych „funkcji”.
CJ7

Odpowiedzi:

14

Widzę to w ten sam sposób. Każda abstrakcja, która nie pozwala ci wejść pod nią w razie potrzeby, jest zła, ponieważ prowadzi do wszelkiego rodzaju brzydkich inwersji abstrakcji w twoim kodzie.

W pracy mamy ORM uczelnię, która działa dość dobrze, ale do czasu, kiedy musimy coś się, że produkt nie przewidują wprost, jest to metoda, która pobiera ciąg i spada bezpośrednio do zapytania To generowanie, pozwalając za korzystanie z surowego SQL, gdy jest to konieczne.

IMO wszelkie ORM, które nie mają tej funkcji, nie są warte bitów, z których zostały skompilowane.

Mason Wheeler
źródło
drops it directly into the query it's generatingBrzmi interesująco. Czy wiesz, jak długo zajęło wam napisać tę uczelnię ORM? Chciałbym zobaczyć coś takiego w jednym z otwartych źródeł ORM.
jblue
+1. Praca z najważniejszym aspektem mojej aplikacji (danych) jest ostatnią rzeczą, którą chcę streścić i stracić połączenie.
Fosco
1
Lubię nurkować w razie potrzeby, o ile nurkowanie pod powierzchnią wymaga przejścia przez metaforyczny płot: „Oto smoki. Uważaj na swój krok”.
Frank Shearar
1
@Jblue: Nie mam pojęcia. Wszystko zostało napisane lata temu, na długo przed tym, jak zostałem zatrudniony. Założyli ORM, zanim ktokolwiek użył tego terminu. Zwykle nazywa się to „modelem obiektowym” w naszej bazie kodów.
Mason Wheeler,
3
Zgadzam się. W przypadku podstawowych i zwykłych rzeczy ORM są bardzo pomocne. Ale czasami trzeba iść trochę głębiej, a jeśli ORM nie daje taką możliwość, to jeszcze jeden źródłem problemów dla Ciebie.
Nikos Steiakakis,
14

ORM przyjmuje najniższy wspólny mianownik

Muszę się nie zgodzić z twoim oświadczeniem. Jako przykład wezmę nHibernate . Ten framework obsługuje wiele baz danych, w tym najpopularniejsze, niezależnie od wersji (i obsługiwanych funkcji), podobnie jak większość ORM.

Szybka uwaga: wspominasz tylko o abstrakcji bazy danych. To jedna z wielu korzyści, ale naprawdę uważam, że funkcje obiektowe mają większą moc (np. Dziedziczenie). I You design your domain model first...

... Powrót do abstrakcji. To nie jest najniższy wspólny mianownik. W nHibernate masz dialekty. Pozwala na użycie tego samego kodu do przeszukiwania różnych baz danych. Dialekty zajmują się zarządzaniem funkcjami. Słuszne jest stwierdzenie, że a given dialect will try to use all the power of a given database system.

Jako przykład weźmy SqlServer2005dialekt, który po wprowadzeniu korzystał z nowych funkcji stronicowania programu SQL Server 2005. Używanie tego dialektu zamiast SqlServer2000zwiększania wydajności.

Oczywiście są wyjątki, ale nie spotkać ani jednego w wielu latach pracy z NHibernate, a moje wnioski są bardzo dane centric.


źródło
+1 za promowanie NHibernate. Trochę krzywej uczenia się w porównaniu do innych ORM, ale wysiłek jest tego wart.
richeym
1
Chciałbym usłyszeć od niektórych DBA na ten temat. Na mojej ostatniej pracy, Hibernate było nic ale kłopot (SQL jest generowane było absolutnie obrzydliwe.)
Fosco
+1 za ten komentarz. Jest na miejscu. Kiedy zaczniesz porównywać moc dobrego ORM, takiego jak nHibernate (z buforowaniem, leniwym ładowaniem itp.), Wtedy zobaczysz, dlaczego ta abstrakcja jest dobra i dlaczego twoje specyficzne potrzeby bazy danych są mniej ważne.
Chris Holmes,
1
Fosco, daj nHibernate kolejną szansę. Jak każdy inny technoloy, musisz zrozumieć, co się dzieje w środku, aby używać go poprawnie.
+1, ORM to maksymalne przecięcie tego, co Java może zrobić z tym, co konkretny sterownik JDBC może zrobić. Możesz wybrać ilość inwestycji, które chcesz poczynić w warstwę trwałości aplikacji
bobah,
5

Pomysł jest zgrabny, ale nigdy nie byłem przeniesiony do tego stopnia, aby używać narzędzia ORM. Po prostu nie było dla mnie problemem, aby sam napisać SQL (lub obsłużyć dowolną używaną pamięć). Ale mam luksus pracy z mniejszą liczbą projektów o dłuższej żywotności produktu, więc gdy ręcznie zakodowane operacje SQL i DB są już na miejscu, są na miejscu. Ponadto, oczywiście, możesz obsłużyć wszelkie bezpośrednie zapytania SQL, których potrzebujesz, bez konieczności dopasowywania swojego procesu do sposobu myślenia narzędzia ORM.

Sądzę więc, że pytania powinny się pojawić, zanim przejdziesz do jednego:

Czy rzeczywiście zyskuje nic z ich użyciem? To znaczy, czy oszczędzasz wystarczająco dużo wysiłku, wdrażając narzędzie ORM, aby było warto z niego korzystać i aby dodać dodatkową komplikację do swojego systemu? (dotyczy to szczególnie aplikacji komercyjnych, w których ten dodatkowy „kawałek” jest teraz dodatkowym wektorem dla potencjalnych problemów z obsługą)

A zatem, czy dodatkowa warstwa abstrakcji będzie miała negatywny wpływ na aplikację? Czy będzie wolniejszy niż ręcznie kodowany SQL itp.

Grandmaster B.
źródło
5

O / RM było regularnie krytykowane. Kilka lat temu Ted Neward nazwał go „ Wietnamem informatyki ”. O / RM

zaczyna się dobrze, staje się coraz bardziej skomplikowany w miarę upływu czasu i wkrótce uwięził swoich użytkowników w zobowiązaniu, które nie ma wyraźnego punktu rozgraniczającego, żadnych jasnych warunków wygranej i jasnej strategii wyjścia.

O ile nie napiszesz tylko własnego mapowania ad-hoc (co w wielu przypadkach jest dobrym rozwiązaniem, jak już powiedzieli inni), możesz przyjrzeć się alternatywom, takim jak użycie nierelacyjnej bazy danych. Niektórzy twierdzą, że prawdziwie obiektowa baza danych jest lepsza, innymi modnymi słowami wymienionymi w tym kontekście są LINQ, Ruby i Tutorial D. Podejrzewam, że w przeciwieństwie do prawdziwie relacyjnych baz danych istnieją naprawdę bazy danych obiektowych. Ale w praktyce odkryłem, że modelowanie danych koncepcyjnych - to znaczy, aby dowiedzieć się, o jakich obiektach świata rzeczywistego chcesz przechowywać dane i jak te obiekty się ze sobą wiążą - jest ważniejsze niż zastanawianie się, jak wyrazić swój model konceptualny w dowolnym język programowania lub bazy danych.

Jakob
źródło
2
Świetnie się tam czytam. Karierę zatoczyłem pełny krąg i z pełnym powodzeniem przyjęłem model relacyjny.
Jé Queue,
2
+1 @Xepoch - Miałem niedawno o twarzy Re: ORMs - dlaczego SQL są pozostawione na mrozie? Oczywiście, abstrakcja - ale ORM zdaje się promować fobię SQL.
sunwukung 10.03.11
1
@ sunwukung, nie zawsze się zgadzałem, ale teraz uważam, że SQL powinien być uważany za warstwę logiczną pierwszej klasy, a nie tylko coś, co jest używane jako protokół przewodowy.
Jé Queue
3

Jaka jest alternatywa?

Jest to ciekawy pogląd. Przez abstrahowanie dala funkcji podstawowej bazy zdecydowanie stracić niektóre z cech wykonania konkretnej bazy danych. (To, czy powinniśmy polegać na określonych funkcjach bazy danych, to kolejny argument). Myślę, że można to rozwiązać za pomocą specyficznych dla bazy danych ORM, które umożliwiają dostęp do określonych funkcji, ale może to być więcej kłopotów niż warte i krok w zły kierunek.

Pod koniec dnia, trzeba zadać sobie pytanie - jaka jest alternatywa?

Powinniśmy przestać używać ORMS i wrócić do pisania wszystko sami dostęp do bazy danych? Na pewno możemy utracić dostęp do kilku funkcji bazy danych za pośrednictwem ORM, ale zawsze możesz uzyskać dostęp do tych, które używają technik starej szkoły. W końcu dostaniesz zyski wydajności całkowicie przewyższają wady.

Jaco Pretorius
źródło
Chciałbym kwestionować potrzebę racjonalnego wykorzystania bazy w ogóle. Niepokoi mnie to, że ludzie natychmiast skaczą do RDBMS, nawet jeśli nie są odpowiednim rozwiązaniem. Bazy danych obiektów, na przykład, zapewniają bardzo eleganckie rozwiązanie wielu problemów. Są one doskonałe? No, ale ludzie rzadko przeszkadza je oceniać. Jest to niepokojący trend, „muszę do przechowywania danych, użyję SQL!”
Matt Olenik
6
@Matt: RDBMS to bardzo wypróbowana i sprawdzona i dobrze zrozumiana technologia. Jest mnóstwo ludzi z doświadczeniem z nimi i duża liczba narzędzi innych firm. Z punktu widzenia przedsiębiorstwa jest to bardzo cenne, gdy mamy do czynienia z czymś niezwykle cennym, takim jak dane. W mniejszych projektach nadal warto mieć możliwość uruchomienia projektu (np. Usługi internetowej LAMP) i posiadania większości oprogramowania w tym miejscu oraz jego dobrze udokumentowanej.
David Thornley,
3

ORM to w zasadzie „ niezapisane procedury ”. Tam ukułem termin.

Wszystko, co robi ORM, można replikować za pomocą widoków, wyzwalaczy i procedur przechowywanych. Pomagają wyodrębnić surowy SQL i mogą zachować spójność znormalizowanych baz danych. Ale działa dobrze tylko w prostych przypadkach. Jeśli istnieje zbyt wiele danych do przetworzenia, mogą one stać się obniżeniem wydajności. (ORM w PHP często biorą stronę po stronie skryptu danych, ponieważ łańcuchy konstruktora SQL nie mogą wszystkiego wyodrębnić).

Ale jak zwykle wszystko zależy od aplikacji i zadania.

Mario
źródło
2
„Procedury niezapisane” - właściwym terminem jest „sparametryzowany SQL”. Jesteś tylko zarysowania powierzchni, co dojrzały ORM może zrobić dla ciebie (grupujących, leniwy załadunku itp)
richeym
@richeym: Większość ORM w PHP nie używa przygotowanych instrukcji ani sparametryzowanych symboli zastępczych. To ucieczka i konkatenacja SQL. Zapewniają one wyższy poziom przewagi nad żmudnymi ręcznymi zapytaniami SQL. Jednak pod względem logicznym pobierają logikę przetwarzania z bazy danych, stąd „procedury niezapisane”.
mario
3

Jedną z rzeczy, która boli przy użyciu ORM, jest to, że wielu ich fanów twierdzi, że nie musimy już znać teorii SQL i RDB. Wyniki różnią się od zabawnych do całkowicie katastrofalnych. I dzieje się tak pomimo miliona razy, gdy producenci i eksperci ORM twierdzą, że musimy dobrze znać teorię SQL i RDB, aby właściwie używać i konfigurować ORM.

Dlaczego ludzie biorą narzędzie, które ma zastosowanie w wielu, ale nie we wszystkich kontekstach, w magiczną, uniwersalną srebrną kulę, jest poza mną.

luis.espinal
źródło
1

W zeszłym roku pracowałem nad aplikacją wewnętrzną, która często się zmieniała i byłem bardzo szczęśliwy, że użyliśmy ORM. Aplikacja była aplikacją wspierającą zespół zarządzający zmianami, a wraz z rozwojem większego projektu nasza mała aplikacja otrzymała nowe wymagania w sytuacjach, które nie istniały i nie można było ich przewidzieć kilka miesięcy wcześniej.

Dzięki ORM ( Propel , w PHP) podzieliliśmy część logiki kodu, więc jedna funkcja dodała część zapytania „jest poprawna”, druga część bezpieczeństwa („pokaż te rekordy tylko wtedy, gdy użytkownik ma te możliwości ”), ... Jeśli zmieniła się podstawowa struktura (dodatkowe pole, które należy wziąć pod uwagę przy„ poprawności rekordu ”), musieliśmy zmienić tylko jedną funkcję, a nie dwadzieścia klauzul SQL.

Wyszliśmy z sytuacji, w której wszystkie (no, większość) klauzule SQL były przechowywane w osobnym pliku XML, więc „zmiany bazy danych byłyby łatwe do obsługi”. Uwierzcie mi, nie byli. Jedna część była tak okropna, że musiałem przesłać ją do The Daily WTF .

Jeśli zapytanie było zbyt skomplikowane, aby wyrazić je za pomocą kryteriów Propela, lub potrzebowaliśmy funkcji specyficznych dla dostawcy (głównie wyszukiwania pełnotekstowego, ponieważ korzystaliśmy z MySQL), nie było to problemem z Propel. Możesz dodać niestandardowe kryteria lub, gdy jest to naprawdę potrzebne, użyliśmy surowego SQL ( teraz jeszcze łatwiejsze do połączenia z rzeczywistymi obiektami Propela). Możesz łatwo dodawać dodatki generowane przez dostawcę do generowanych klas, dzięki czemu masz to, co najlepsze z obu światów: bez kodu SQL w kodzie aplikacji, ale ze wszystkimi możliwościami silnika bazy danych.

Jan Fabry
źródło
1

Ale chodzi o to, że możesz programować z dala od bazy danych, co oznacza, że ​​nie musisz myśleć tak, jakbyś był w bazie danych.

Pracuję teraz w C # i dużo używam LINQ, więc wiele płynnych metod. Nie muszę myśleć o tym, jak moje obiekty są przechowywane lub znalezione, a nawet zapisane na poziomie programu, a bardzo mało na poziomie warstwy biznesowej.

Dość często metody dostarczane przez same Specyficzne Bazy Danych są używane w Konstruktorze DB, więc uzyskujesz te optymalizacje bez konieczności poznawania ich.

Nadal możesz pisać funkcje po stronie DB. Często możesz je po prostu zmapować.

A przede wszystkim taka separacja pozwala na testowanie i zmusza cię (trochę) do napisania lepiej ustrukturyzowanego kodu

ręka spalona
źródło
2
Ponownie, dlaczego trzeba programować z dala od bazy? Dlaczego nie uczynić bazy danych integralną częścią twojego rozwoju, ponieważ wybrałeś korzystanie z niej w pierwszej kolejności. Jeśli nie potrzebujesz RDBMS, po co wsuwać na niego ORM?
Je Kolejka
1
Jest integralną częścią. Baza danych bardzo dobrze radzi sobie z utrzymywaniem i egzekwowaniem relacji oraz odzyskiwaniem surowych danych. Jednak rzeczy, które chcesz zrobić z tymi danymi, najprawdopodobniej były już obsługiwane w opakowaniu ORM. A poza krytycznymi rzeczami, po co logikę z warstwy biznesowej?
burnt_hand
@burnt_hand - „Chodzi o to, że musisz programować z dala od bazy danych, co oznacza, że ​​nie musisz myśleć, jakbyś był w bazie danych”. Jakie są uniwersalne zalety? Widzę to jako zaletę, gdy Twoja aplikacja po prostu szuka sposobu na utrwalenie obiektów. Ale w przypadku danych relacyjnych, OLTP i tym podobnych, programowanie poza bazą danych jest jednym ze sposobów na spędzenie czasu.
luis.espinal
@ luis.espinal - co to znaczy spieprzyć samego siebie? jestem naprawdę ciekawy. Czy masz przykład?
burnt_hand
@burnt_hand - rzeczywiście mam kilka prawdziwych przykładów. Najnowszy dotyczy bardzo dużego modelu domeny i ze względu na wydajność, projekt musi przesłać wszystkie hibernacyjne mapowania przy uruchomieniu. Powstała fabryka sesji zużywa do 30% używanej pamięci ... tylko na powiązania. Baza kodu jest teraz zbyt zaangażowana w ORM i nie można jej przepisać. Ma to teraz rzeczywiste implikacje, ponieważ aplikacja zbliża się do fizycznych ograniczeń sprzętu, który miał działać. Porażka.
luis.espinal
1

ORM mogą również zapewniać dostęp do funkcji specyficznych dla bazy danych, zależy to od używanej ORM i funkcji, które oferuje.

Na przykład w bieżącym projekcie, nad którym pracuję, używamy interfejsu API Java Persistence i Hibernacji. Mimo to korzystamy z kilku funkcji specyficznych dla bazy danych, takich jak wyszukiwanie w tabelach za pomocą soundex.

Dla mnie główną zaletą korzystania z ORM niekoniecznie jest to, że sprawia, że ​​baza danych aplikacji jest agnostyczna (chociaż jest to również dobra rzecz), ale że w większości nie muszę myśleć o tym, jak rzeczy są przechowywane i odzyskano.

Jednak w pewnym momencie najprawdopodobniej będziesz musiał o tym pomyśleć, w zależności od wymagań aplikacji. ORM nie jest magią.

Vetle
źródło
1

Napisałem własną, która pomaga mi łatwiej wybierać i wstawiać.

Evey db konkretna rzecz jest dostępna. Muszę tylko napisać zapytanie, w którym biblioteka mi pomaga (mogę użyć „?” I parametrów zamiast ręcznie nazwać parametr i użyć .Dodaj)

Wydaje mi się, że mój w połowie jest do bani, w połowie użyteczny. Otrzymuję pomoc w świecie ORM i wykonuję znaczące części w świecie zapytań.


źródło
1

Pisanie kodu do wstawiania i wybierania, aktualizowania w trybie wbudowanym lub z zachowanymi procesami i mapowanie ich z powrotem przez DAL jest dłuższą normą, a raczej tylko w wyjątkowym przypadku. Dostępne ORM, bazy danych i języki pytanie, które powinieneś zadać, dlaczego nie używasz ORM?

Są znormalizowane, uniwersalne, określone lub ogólne. ponadto jest szybszy i łatwiejszy do wdrożenia. Użyłem subsonicznego, linq-to-sql i frameworku encji. Pozwala deweloperowi skoncentrować się na logice i regułach biznesowych zamiast na mapowaniu bazy danych.

Nickz
źródło
1
Istnieje wiele powodów, aby używać lub NIE używać ORM. ORM nie są panaceum i bardzo niewiele osób faktycznie wie, jak je skutecznie wykorzystywać. Ponadto w wielu przypadkach logika biznesowa jest już odzwierciedlona (częściowo) w bardzo naturalny sposób w relacjach już istniejących w RDBMS (był to najczęstszy scenariusz, z jakim się spotkałem, przeszłość i teraźniejszość). Dobrze zaprojektowany RDBM ma silne, zrozumiałe, wypróbowane i prawdziwe podstawy matematyczne. Oczywiście nie wszystko powinno być modelowane za pomocą RDMB, ale równie dobrze ORM nie jest rozwiązaniem uniwersalnym.
luis.espinal
1

Moje (proste) dwa centy:

1: Istnieją ORMS i są ORMS. Niektóre ORMS opierają się na Active Record, inne na Data Mapper - to samo w sobie jest istotną kwestią, ale wymagającą pewnych badań, aby zrozumieć konsekwencje. Ogólnie - z mojego doświadczenia w PHP wynika, że ​​ORMS obsługuje te pierwsze, a niewielu to drugie. Wydaje się, że ORM oparte na Active Record mają jeden z dwóch efektów - albo znormalizują bazę danych, albo wywołują mnóstwo klas w celu obsługi interakcji z obiektami.

2: Zalety ORM zmniejszają się w bezpośredniej korelacji ze złożonością zapytania, które należy uruchomić. Kiedy masz przyjemną, prostą relację - tj. Użytkownicy -> Posty, mogą one działać bardzo dobrze. To (IMO) dlatego większość ORM / frameworków używa takich przykładów. Jednak gdy trzeba uruchamiać złożone zapytania, ilość ORMQL, którą należy wygenerować, jest porównywalna z długością łańcucha zwykłego zapytania SQL - ale mniej wydajna ze względu na graf obiektowy uruchamiający zapytanie, który to rodzaj pokonuje punkt abstrakcja. Krótko mówiąc - ORM są genialne dla pierwszych 30-50% zadań w bazie danych - ale okropne dla ostatnich. Myślę, że to kolejny powód, dla którego AR jest tak rozpowszechniony.

3: Po co ukrywać się przed bazą danych? Czy użyłbyś języka po stronie serwera do abstrakcyjnego javascript?

Osobiście łączę te podejścia:

  • użyj ORM do podstaw, ładując „użytkowników”
  • użyj DAO zawierającego kilka gotowych zapytań SQL (tj. selectLike, selectWhere).
  • w razie potrzeby rozszerz DAO, aby dodać bardziej szczegółowe, ale wielokrotnego użytku zapytania niestandardowe
  • Zapewnij prosty dostęp do bazy danych za pośrednictwem DAO - tj. $ Data = Dao-> zapytanie (ciąg SQL), aby wykonać jednorazowe zapytania.

Powiedziawszy to wszystko, wkrótce pojawi się Doctrine 2, co wygląda naprawdę interesująco.

sunwukung
źródło
0

Możesz użyć struktur mapujących SQL, takich jak myBatis, jeśli chcesz korzystać z funkcji SQL.

kołchanov
źródło
To nie jest tak naprawdę odpowiedź na pytanie jblue o korzyściach płynących z używania takiego mapera
Lukas Eder,