Używasz ORM lub zwykłego SQL? [Zamknięte]

W przypadku niektórych aplikacji, które opracowałem (potem zapomniałem), piszę zwykły SQL, głównie dla MySQL. Chociaż używałem ORM w pythonie, takich jak SQLAlchemy , nie trzymałem się ich długo. Zwykle powstrzymywała mnie dokumentacja lub złożoność (z mojego punktu widzenia).

Widzę to tak: użyj ORM dla przenośności, zwykłego SQL, jeśli tylko będzie korzystał z jednego rodzaju bazy danych. Naprawdę szukam porady, kiedy używać ORM lub SQL podczas tworzenia aplikacji, która wymaga obsługi bazy danych.

Myśląc o tym, zdecydowanie lepiej byłoby użyć lekkiego opakowania do obsługi niespójności bazy danych niż przy użyciu ORM.

ORM mają kilka fajnych funkcji. Potrafią poradzić sobie z wieloma problemami związanymi z kopiowaniem kolumn bazy danych do pól obiektowych. Zwykle obsługują konwersję typów daty i godziny języka na odpowiedni typ bazy danych. Zazwyczaj bardzo elegancko obsługują relacje jeden do wielu, tworząc instancję obiektów zagnieżdżonych. Przekonałem się, że jeśli projektujesz swoją bazę danych z uwzględnieniem mocnych i słabych stron ORM, oszczędza to dużo pracy przy pobieraniu i wyprowadzaniu danych z bazy. (Jeśli chcesz je zmapować, będziesz chciał wiedzieć, jak radzi sobie z polimorfizmem i relacjami wiele do wielu. To te dwie domeny zapewniają większość „niedopasowania impedancji”, przez co niektórzy nazywają ORM „wietnamem informatyki” .)

W przypadku aplikacji transakcyjnych, tj. Składających żądanie, pobierających niektóre obiekty, przechodzących je w celu uzyskania niektórych danych i renderowania ich na stronie internetowej, podatek od wydajności jest niewielki, aw wielu przypadkach ORM może być szybszy, ponieważ buforuje obiekty, jak widzieliśmy wcześniej, w przeciwnym razie wielokrotnie sprawdzałby bazę danych.

W przypadku aplikacji, które są obciążone raportowaniem lub zajmują się dużą liczbą wierszy bazy danych na żądanie, podatek od ORM jest znacznie wyższy, a buforowanie, które wykonują, staje się dużym, bezużytecznym obciążeniem pamięci. W takim przypadku wystarczy proste mapowanie SQL (LinQ lub iBatis) lub ręcznie kodowane zapytania SQL w cienkim DAL.

Znalazłem dla każdej aplikacji na dużą skalę, którą znajdziesz przy użyciu obu metod. (ORM dla prostych CRUD i SQL / cienkich DAL do raportowania).

Mówiąc jako ktoś, kto spędził sporo czasu pracując z JPA (Java Persistence API, w zasadzie znormalizowany ORM API dla Java / J2EE / EJB), który obejmuje Hibernate, EclipseLink, Toplink, OpenJPA i inne, podzielę się niektórymi moimi obserwacje.

1. ORM nie są szybkie. Mogą być odpowiednie i przez większość czasu wystarczające jest OK, ale w środowisku o dużych opóźnieniach i małych opóźnieniach są nie-nie;
2. W językach programowania ogólnego przeznaczenia, takich jak Java i C #, potrzeba ogromnej ilości magii, aby mogły działać (np. Tkanie w czasie ładowania w Javie, oprzyrządowanie itp.);
3. Korzystając z ORM, zamiast wchodzić dalej w SQL (co wydaje się być intencją), będziesz zaskoczony, ile czasu spędzasz na ulepszaniu XML i / lub adnotacji / atrybutów, aby ORM wygenerował wydajny SQL;
4. W przypadku złożonych zapytań tak naprawdę nie ma substytutu. Podobnie jak w JPA, istnieje kilka zapytań, które po prostu nie są możliwe, które są w surowym SQL, a kiedy trzeba użyć surowego SQL w JPA, to nie jest ładne (C # /. Net przynajmniej ma typy dynamiczne - var - co jest dużo ładniejszy niż tablica obiektów);
5. Podczas korzystania z ORM jest bardzo dużo „gotchas”. Obejmuje to niezamierzone lub nieoczekiwane zachowanie, fakt, że musisz wbudować możliwość wykonywania aktualizacji SQL bazy danych (za pomocą funkcji refresh () w JPA lub podobnych metodach, ponieważ JPA domyślnie buforuje wszystko, aby nie przechwycić bezpośredniej bazy danych aktualizacja - uruchamianie bezpośrednich aktualizacji SQL jest częstym działaniem wspierającym produkcję);
6. Niedopasowanie obiektowo-relacyjne zawsze będzie powodować problemy. Przy każdym takim problemie występuje kompromis między złożonością a kompletnością abstrakcji. Czasami czułem, że JPA posunął się za daleko i osiągnął prawdziwe prawo malejących zwrotów, w których złożoność nie była uzasadniona abstrakcją.

Jest jeszcze jeden problem, który wymaga nieco więcej wyjaśnień.

Tradycyjny model aplikacji internetowej ma warstwę utrwalającą i warstwę prezentacji (być może z usługami lub innymi warstwami pomiędzy nimi, ale są to dwie ważne w tej dyskusji). ORM wymuszają sztywny widok od twojej warstwy trwałości do warstwy prezentacji (tj. Twoich jednostek).

Jedną z krytyk bardziej surowych metod SQL jest to, że otrzymujesz wszystkie VO (obiekty wartości) lub DTO (obiekty przesyłania danych), które są używane przez jedno zapytanie. Jest to reklamowane jako zaleta ORM, ponieważ się tego pozbywasz.

Chodzi o to, że problemy te nie znikają z ORM, po prostu przechodzą do warstwy prezentacji. Zamiast tworzyć VO / DTO dla zapytań, tworzysz niestandardowe obiekty prezentacji, zwykle po jednym dla każdego widoku. Jak to jest lepsze? IMHO nie jest.

Pisałem o tym w ORM lub SQL: Czy już tam jesteśmy? .

Moją wybraną obecnie technologią trwałości (w Javie) jest ibatis. Jest to dość cienkie opakowanie wokół SQL, które robi ponad 90% tego, co potrafi JPA (może nawet leniwie ładować relacje, chociaż nie jest to dobrze udokumentowane), ale ma znacznie mniejszy narzut (pod względem złożoności i faktycznego kodu).

Tak było w zeszłym roku w aplikacji GWT, którą pisałem. Wiele tłumaczeń z EclipseLink na obiekty prezentacji w implementacji usługi. Gdybyśmy korzystali z ibatis, znacznie łatwiej byłoby stworzyć odpowiednie obiekty za pomocą ibatis, a następnie przekazać je w górę iw dół stosu. Niektórzy puryści mogą argumentować, że to Bad ™. Być może tak (teoretycznie), ale powiem ci: co prowadziłoby do prostszego kodu, prostszego stosu i większej wydajności.

Mówię zwykły SQL dla R eadów, ORM dla CUD .

Wydajność jest czymś, co zawsze mnie martwi, szczególnie w aplikacjach internetowych, ale także łatwość utrzymania kodu i czytelność. Aby rozwiązać te problemy, napisałem SqlBuilder .

ORM to nie tylko przenośność (co jest dość trudne do osiągnięcia nawet w przypadku ORM). To, co daje, to w zasadzie warstwa abstrakcji nad trwałym sklepem, gdy narzędzie ORM uwalnia cię od pisania zapytań SQL typu „podstawowa” (wybieranych przez PK lub według predykatów, wstawiania, aktualizacji i usuwania) i pozwala ci skoncentrować się na domenie problemowej.

Każdy poważny projekt będzie wymagał pewnej abstrakcji dla bazy danych, aby poradzić sobie z niedopasowaniem impedancji. Ale najprostszym pierwszym krokiem (i odpowiednim dla większości przypadków), jakiego oczekiwałbym, byłby DAL, a nie ciężki ORM. Twoje jedyne opcje nie są na końcu spektrum.

EDYCJA w odpowiedzi na komentarz z prośbą o opisanie, w jaki sposób odróżniam DAL od ORM:

DAL jest tym, co sam piszesz, być może zaczynając od klasy, która po prostu kapsułkuje tabelę i mapuje jej pola na właściwości. ORM to kod, którego nie piszesz, ani mechanizmy abstrakcyjne wywodzące się z innych właściwości schematu dbms, głównie PK i FK. (W tym miejscu dowiadujesz się, czy automatyczne abstrakcje zaczynają być nieszczelne. Wolę informować je celowo, ale to może być moja osobista preferencja).

Każde narzędzie ma swój cel i wizję. Stworzyłem http://www.jooq.org/ dokładnie dla twoich potrzeb, choć iBatis jest prawdopodobnie również dobrym rozwiązaniem dla ciebie.

jOOQ ma podstawowe funkcje ORM, ale koncentruje się głównie na rzeczach, które, jak sądzę, najbardziej potrzebują programiści, gdy starają się znaleźć najlepszą ORM dla swoich potrzeb:

• generowanie kodu
• zmienne wiązanie (to jest problem w JDBC)
• Abstrakcja składni SQL (aby zapobiec błędom składni)

Ale często posuwają się za daleko i zapewniają tak dużo abstrakcji, że nie sądzisz, że działają przeciwko RDBMS. Z drugiej strony wybrałeś RDBMS właśnie dlatego

• to solidne źródło danych
• SQL potrafi wiele dobrych, wydajnych rzeczy (zagnieżdżone selekcje, związki, złożone sprzężenia itp.). Często ORM nie może robić tych rzeczy.
• możesz samodzielnie obsługiwać transakcje i sesje
• masz UDT i procedury składowane

jOOQ zajmuje się dokładnie tymi punktami. Będzie działał równie dobrze jak JDBC, ale bez bólu.

Dylemat, czy używać frameworka, czy nie, jest dość powszechny we współczesnym scenariuszu tworzenia oprogramowania.

Ważne jest, aby zrozumieć, że każda struktura lub podejście ma swoje zalety i wady - na przykład z naszego doświadczenia wynika, że ​​ORM jest przydatny w transakcjach, tj. Operacjach wstawiania / aktualizacji / usuwania - ale w przypadku pobierania złożonych danych wyniki staje się ważne, aby ocenić wydajność i skuteczność narzędzia ORM.

Ważne jest również, aby zrozumieć, że nie jest obowiązkowe wybranie ram lub podejścia i wdrożenie w tym wszystkiego. Rozumiemy przez to, że możemy mieć połączenie ORM i natywnego języka zapytań. Wiele frameworków ORM daje punkty rozszerzeń wtyczki w natywnym SQL. Powinniśmy starać się nie używać nadmiernie ram ani podejścia. Możemy łączyć określone ramy lub podejścia i dostarczać odpowiednie rozwiązanie.

Możesz użyć ORM, jeśli chodzi o wstawianie, aktualizację, usuwanie, wersjonowanie z wysokim poziomem współbieżności, a także możesz używać Native SQL do generowania raportów i długich list

Kluczem, który sprawił, że mój ORM naprawdę zaczął latać, było generowanie kodu. Zgadzam się, że trasa ORM nie jest najszybsza pod względem wydajności kodu. Ale kiedy masz średni lub duży zespół, DB szybko zmienia zdolność do regeneracji klas i mapowań z DB jako część procesu kompilacji, jest to coś wspaniałego do zobaczenia, szczególnie gdy używasz CI. Twój kod może nie być najszybszy, ale kodowanie będzie - wiem, co bym wziął za większość projektów.

Moje zalecenie to opracowanie przy użyciu ORM, gdy schemat jest jeszcze płynny, skorzystaj z profilowania, aby znaleźć wąskie gardła, a następnie dostrój te obszary, które tego potrzebują, używając surowego Sql.

Inna myśl, buforowanie wbudowane w Hibernację może często znacznie poprawić wydajność, jeśli jest używane we właściwy sposób. Nie trzeba już wracać do bazy danych, aby odczytać dane referencyjne.

Nie ma rozwiązania „jedno narzędzie dla wszystkich”, a dotyczy to również pytania „czy powinienem używać or / m, czy nie? „.

Powiedziałbym: jeśli musisz napisać aplikację / narzędzie, które jest bardzo „skoncentrowane na danych”, bez większej logiki, użyłbym zwykłego SQL, ponieważ SQL jest językiem specyficznym dla domeny dla tego rodzaju aplikacji.

Z drugiej strony, gdybym miał napisać aplikację biznesową / korporacyjną, która zawiera dużo logiki „domeny”, napisałbym bogaty model klasy, który mógłby wyrażać tę domenę w kodzie. W takim przypadku maper OR / M może być bardzo pomocny, aby to zrobić skutecznie, ponieważ wymaga dużo kodu instalacyjnego z twoich rąk.

Jedną z opracowanych przeze mnie aplikacji był bot IRC napisany w języku python. Moduły, których używa, działają w osobnych wątkach, ale nie znalazłem sposobu na obsługę wątków podczas korzystania z sqlite. Chociaż może to być lepsze w przypadku osobnego pytania.

Naprawdę powinienem był przeredagować zarówno tytuł, jak i pytanie. Nigdy wcześniej nie korzystałem z DAL w żadnym języku.

Użyj ORM, który działa jak SQL, ale zapewnia sprawdzanie czasu kompilacji i bezpieczeństwo typu. Podobnie jak moje ulubione: Data Knowledge Objects (ujawnienie: napisałem to)

Na przykład:

for (Bug bug : Bug.ALL.limit(100)) {
  int id = bug.getId();
  String title = bug.getTitle();
  System.out.println(id +" "+ title);
}

Pełna transmisja strumieniowa. Łatwy w konfiguracji (brak mapowań do zdefiniowania - odczytuje istniejące schematy). Obsługuje sprzężenia, transakcje, zapytania wewnętrzne, agregację itp. Niemal wszystko, co możesz zrobić w SQL. Udowodniono to od gigantycznych zestawów danych (finansowe szeregi czasowe) aż po trywialne (Android).

Wiem, że to pytanie jest bardzo stare, ale pomyślałem, że opublikuję odpowiedź na wypadek, gdyby ktoś trafił na nią tak jak ja. ORM przeszły długą drogę. Niektóre z nich zapewniają najlepsze z obu światów: zwiększanie produktywności i utrzymanie wydajności.

Spójrz na dane SQL ( http://sqldata.codeplex.com ). Jest to bardzo lekki ORM dla c #, który obejmuje wszystkie podstawy.

Do Twojej wiadomości, jestem autorem danych SQL.

Chciałbym dodać mój głos do chóru odpowiedzi, które mówią „Jest środek!”.

Dla programisty aplikacji SQL jest mieszanką rzeczy, które możesz chcieć kontrolować i rzeczy, których prawie na pewno nie chcesz mieć problemów z kontrolowaniem.

To, czego zawsze chciałem, to warstwa (nazywam to DAL, ORM lub mikro-ORM, nie mam znaczenia, która), która zajmie się całkowicie przewidywalnymi decyzjami (jak przeliterować słowa kluczowe SQL, gdzie idą nawiasy, kiedy wymyślić aliasy kolumn, jakie kolumny utworzyć dla klasy, która zawiera dwa zmiennoprzecinkowe i int ...), pozostawiając mnie odpowiedzialnym za aspekty SQL wyższego poziomu, tj. jak organizować JOIN, obliczenia po stronie serwera, ODLEGŁOŚCI, GROUP BY, podkwerendy skalarne itp.

Więc napisałem coś, co to robi: http://quince-lib.com/

To jest dla C ++: nie wiem, czy to jest język, którego używasz, ale mimo wszystko może być interesujące zobaczyć to spojrzenie na to, jak mógłby wyglądać „środek”.