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

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?

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.

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.

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.

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.

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.

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.

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

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.

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

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

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

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.

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.

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