ORM pro es contra

Adatbázis: SQL, XML DB

A kerdes egyszeru: hasznalsz-e object-relational mapping-ot? Ha igen miert, ha nem miert?

  • 2059 megtekintés

( pwm | 2009. 06. 04., cs – 19:55 )

Reszemrol mindig kacerkodom a gondolattal egy uj project kapcsan, hogy na, most szigoruan csak ORM lesz, aztan valahogy mindig oda lyukadok ki, hogy jon egy problema, amire nem tudom rahuzni (valszeg mert bena vagyok), es igy marad a plain SQL.

( efpe | 2009. 06. 04., cs – 20:16 )

Symfony + Doctrine. Eddig mindent sikerult megoldani vele. Sebessegrol most ne beszeljunk..

Bocs kicsit hosszu lesz:

Legutobb egy olyan problemat kellett megoldanom, hogy adott egy lista, ami a listaelemek egy bizonyos erteke szerint rendezve van, de ha tobb elemnek ugyanaz az az erteke, akkor koztuk lehessen rangsorolni.

Pelda:

listaelemek: a,b,c,d,e,f

ertekek: a->e=1, b->e=2, c->e=2, d->e=2, e->e=2, f->e=3
(ahol e az adott elem erteke, ami egy szamitas vegeredmenye, es idoben folyamatosan valtozik minden elemre)

ekkor a rang alapesetben igy nez ki:
a->r=1, b->r=1, c->r=2, d->r=3, e->r=4, f->r=1
(ahol r az adott elem rangja a csoporton belul)

Azaz minden "e csoporton" belul van egy belso rangsor.

Namost tfh. egy, az e=2 csoporton beluli elemnek meg akarod valtoztatni a csoporton beluli rangjat, pl: b-nek 1-rol 3-ra.

Ezt talaltam ra ki: 


"UPDATE blabla SET rank = IF(id = 2, 3, IF((rank > 1 AND rank <= 3), rank - 1, rank)) \
WHERE id in (2,3,4,5) ORDER BY rank"

ahol a (2,3,4,5) a b,c,d es e elemek id-ja. (amugy ez csak az egyik irany, a masiknal rank-1 helyett rank+1 kell)

Na kerdes hogy erre es a hasonszuro problemakra hogy huzza ra az ember az ORM technikat? Szvsz sehogy.

Nyilvan olyan ORM megoldasoknal, ahol van fejlett belso query language meg lehet csinalni (pl: JPQL), de ott meg azt nem ertem, hogy akkor meg miert bajlodni meg egy extra reteggel?

Valaki gyozzon meg :)

( gee v | 2009. 06. 04., cs – 22:42 )

Valaki írja meg, hogy ez mikor és mire jó... de nem elméleti példára vágyok, hanem valósra.

Valahogy 98-99 körül Oracle8-cal, vagy 8i-vel próbálkoztam, mert hogy ha már tud ilyesmit, milyen frankó, majd a C++ programból az objektumokat simán beletolom.

Készítettem egy modelt, volt benne egy VARRAY, ha jól emlékszem.

Nem volt túl egyszerű megcsinálni a lekérdezéseket, de a végén ment minden. Viszont iszonyú lassú volt. Rettenetesen.

Az egészet sima relációs táblában eltárolva mondjuk egy hívás adat fájl beolvasása lemezről adatbázisba lement kb. 20 percről kb. 50 másodpercre.

Azóta nem próbálkoztam vele, persze lehet, hogy mondjuk volt valami hiba, amit azóta javítottak, és már nem lenne lassú...

Csak épp azt nem tudom, hogy mire lenne ez nekem jó.

Programozni kb. 95 óta csak OOP-ben programozok, tehát nem magát az objektum koncepciót nem értem.
Csak azt, hogy ha tegyük fel adatbázisban objektumként definiálom, akkor miért és hogyan jobb nekem.

Olyasmi dolgokat várok, hogy pl. van valami összetett objektum, láncolt listával, tömbbel, és nem kell ciklust írni meg több lépésben feldolgozni, hanem egy utasítás...

Mert ha kevesebbet kell gépelni, kisebb a hibalehetőség. Ha sebességre kb. ugyanaz, akkor meg is van, hogy miért jobb.

Szóval valós életbeli igazi példákat várnék, hogy mondjuk adott projektben ezt használta valaki, és jó volt, mert...

G

miert jo?
- gyorsabb fejlesztesi ido (melyik a jobb: dbt kezelgetni, vagy az entitasaidat?)
- kevesebb hibalehetoseg
- jobb adatbazis (ne mondd, h webes pistike tudja, mi az a foreign key, mert szerintem nem)

az a +1 extra layer sebessegben nem sokat vesz le, viszont fejleszteni jo dolog benne.

gyakorlati pelda: a cegnel nalunk az adatbazis eleg nagy (~50 tabla, >100millio rekord), es ORMen keresztul eri el a Java EE -s kezelorendszer. (sot, a semat is auto generaltattuk)

Kizarolag ORM(hibernate? EJB?) vagy kevert?
A nem trivialis sql parancsokkal (amit pl fentebb is emlitettem, ami amugy semmi extra, csak van benne egy csopp logikai resz es nem csak select innen join onnan) mit csinaltok?
Belegyomoszolitek valahogy ORM-be (ha igen hogy? :)), vagy inkabb middleware-ben irjatok az ilyesfajta logikat?

kizarolag JPA, hogy pontosak legyunk. ott a full stack, ORMnek magaban mi ertelme lenne? :)
mint irtam Java EE. nalunk ez most most ugy nez ki, hogy JAX-WS + EJB + JPA + JMS (OpenMQ). kesobb jon majd me'g OpenESB a kepbe.

ha ilyet akarsz csinalni, arra ott a JPQL. ha valamit nem tud, akkor meg me'g mindig lehet native queryt irni, ami objektumra mappelodik vissza (EntityManagernek van createNativeQuery metodusa, class parameterrel, amire visszameppel).

ezt meg ugye EJBbol hivhatod (nalam az EJB az nem middleware.. :))

Iszonyuan meg tudja dobni a fejlesztes sebesseget olyan projekteknel, amik nem kimondottan adnak bonyolult lekerdezeseket. Csak pelda: en korulbelul ket het alatt dobtam ossze egy olyan adatbazisreteget, ami szukseges volt egy leltarprogram alapjaihoz. A ket het utani allapot olyan volt, hogy az eloirasoknak megfeleloen mukodott, de nagyon sok szelsoseges esetet nem volt kepes lekezelni. Ehhez kepest ha ORM-mel fejlesztettem volna mar akkor, azt a ket hetet kihagyhattam volna a projekt fejlesztesi idejebol.

Olyan helyeken, mint leltarprogram, blog, forum, webshop, hirportal nem a lekerdezes a lenyeg, hanem hogy megszerezd a vagyott objektumot minel egyszerubben es gyorsabban, hogy tudj tovabb dolgozni vele.

Nyilvan nem lehet ugy gondolkodni egy ORM projekt kapcsan mint egy pure SQL rendszer kapcsan, mindig lehetnek olyan feladatok, amiken sokat kell gondolkodni. Nehany ORM rendszer ad SQL injektalasi lehetoseget a feltetelek menten, masok kulon kiertekelo nyelvet adnak, ismet masok egyaltalan nem segitenek, es sokkal tobb adatot kell eloszedned, mint szeretned. De mindig mondom: a cel valaszt eszkozt, es nem forditva. Vannak dolgok, amikben gyengek az ORM rendszerek, van par dolog, amit nem lehet a keretrendszer mely modositasa nelkul megvalositani, nehany feladatot meg ezzel egyutt se; nyilvan ilyen helyre nem teszunk ilyen rendszert. Be kell tervezni, hogy a projekt soran egy verziot fullkomplette el fogsz dobni, ugyis eldobod; akkor inkabb mar igazodj a tervhez, mintsem kinlodj.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Jo hozzaszolas, akarom mondani +1
Valahogy en mindig olyan projectekbe futok bele, amikben kellenek a szokasostol eltero lekerdezesek/modositasok, es jo esetben ez mar a tervezesi fazisban ki szokott derulni.
Kapcsolodo dilemma, hogy gyakorlatilag minden bonyolult sql logikajat meg lehet irni middleware szinten, es onnantol szinte tenyleg csak egyszeru CRUD, ami ugye szep lesz ORM-el, de ekkor meg sztem "amit nyersz a reven,azt elveszited a vamon".

Hat ez megintcsak attol fugg, mert ugye a kod relative egyszerusege es atlathatosaga a kesobbi javitasokkor kamatozik sokat. En peldaul a fent emlegetett adatbazisreteget mar nem biztos, hogy rogton atlatnam, ha problema lenne, pedig nem egy ordongosen bonyolult valami. Gondolkodtam mar rajta, hogy elrettento peldanak feldobom a blogomra egy entitas felepiteset - azert az ORM mapping-hoz valo differenciat nagyon szepen lehet rajta latni - de sajnos zart forrasu, ujra meg mar nem implementalnam. Majd talan ha mar nem itt dolgozok...

Megint csak momentum: az egesz arra epult, hogy minden "entitas" osztalynak van egy parja az adatbazisretegben, ami a db muveleteket kuloniti el az effektiv entitasmuveletektol. Ebben gyakorlatilag a Java alap SQL keszletet alkalmazva bontogatom ki az adatbazis tartalmat, es toltok fel egy ures entitast adatokkal. Az adatbazis felol jovo adatokban kenyszeru vagyok maximalisan megbizni, hiszen ezen a szinten semmi eselyem validalni oket (van egy allapota a rendszernek, ahol pl. a kotelezo adatok hianyoznak). Ami jo volt benne, hogy egeszen vad dolgokat is meg lehetett csinalni, peldaul parameterul kapott komplett WHERE SQL snippetek menten keresni. Ezt persze ma mar nem biztos, hogy meg mernem lepni, foleg nem ellenorizetlenul.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

( tovis v | 2009. 06. 06., szo – 14:13 )

Sajnos az ORM még kicsit sötét nekem. Viszont a windows/DOS világban létezik/létezett egy olyan fejlesztői keretrendszer mint a Clarion (jelenleg a 7 verzióját dobták piacra). Itt egy külön felületen, olyan szintig le kell írnod az adatbázist, hogy még a megjelenítés módját is megadhatod, "eljárás" függően (form,browse,report ...). A végeredmény egy "dictionary" nevezetű bináris állomány (tulajdonképpen egy adatbázis, az adatbázisodról) ami nem csak típusokat, kulcsokat, relációs kapcsolatokat (és azok hogyan kezelendők).
Amennyiben, a részletes és hibátlanul elkészített adatbázis modell megvan, ennek birtokában:
- generálhatsz egy komplett aplikációt, mely a "dictionary" összes adattáblájára készít brwose, form és report eljárásokat - 1 perc és kész a demo. Lépésről, lépésre is készítheted az aplikációt, úgy hogy konkrétan megmondod milyen típusú eljárás (browse/form/report) kell és ezek milyen sorrendben hogyan érhetőek el.
- az elkészült generált kódba, meghatározott helyeken beszúrhatod a saját kódodat (ha erre van szükség), ezeket külön kezeli, és ha a generálás feltételei megváltoznak (pl. módosítasz az adatbázison) akkor sem bántja ezeket a kódokat.
- néhány mozdulattal, áttérhetsz az egyik adabázis motorról a másikra (persze ez itt kb. egy tucat lehet és mind a fizetős kategória).
Ami nagyon fontos, és ebbe a felsorolásba nem igazán illeszkedik az az, hogy kódgenerálás, nem valami belső mágia, hanem egy méretes template készlettel történik. A programozó módosíthat és készíthet template -ket. Számos, mások által létrehozozott template -ből is dolgozhatsz (van free és vastagon fizetős).
A lényeg, hogy az egész két alapvető elemre épül, az adabázis absztrakt és minél precízebb leírása, és a template nyelvezeten. Mindehhez természetesen van egy rendkívül megbízható és hatékony adatbázis manipulációs eljárás library (C -ben megírva), amire ráhúznak egy objektum könyvtárat és mellé tesznek egy compilert. A végeredmény exe és dll -ek formájában (a régi DOS verzióban még overlay is volt). A komplett csomag egyébként tartalmaz C, pascal, modula-2 compilerrt is!
A képernyőket/reportokat egy wisiwyg szerkesztőben készítheted (már amennyiben a windows wisiwyg). Szóval nagyon kitűnő és hatékony eszközről van szó.
Hátrányok:
- k'rva drága (professional 1000$ és enterprise 2000$)
- minden féle finomság hasonló árakon plusszban
- csak windows
- a dictionary szerkesztőben minbden windows paneleken zajlik,
nem jól áttekinthető, kereshető stb.

Konklúzió: Az ORM nem tudom hogy jó lessz-e, nekem a fent leírtakhoz képest kicsit aláméretezettnek tűnik, de kiinduló pontnak jó. A lényeg hogy elvonatkoztathassunk az adatbázis motortól és a minél jobban támaszkodjunk az adat struktúrák specifikációjához, hiszen ott minden le van írva, még az applikáció is, csak értelmezni kell és jöhet a design. Ez a dolog előre mutat és hajtani kell!

Bocs hogy lyukat írtam a hasatokba! - de így talán érthető. Én több (nem, WEB -es) projectet megcsináltam a 4.x verzióval. De a további munkához túl nagy befektetés, ezt nem látom hogy tudom kitermelni :(

UI: volt egyszer egy Clarion for Linux opensource project is de sajnos hamvában holt :(

* Én egy indián vagyok. Minden indián hazudik.

( zmb | 2009. 06. 07., v – 18:28 )

Tovabbi erdekes tulajdonsagai az orm-nek:
- (Kicsit nagyon marketing szagu) Az sql-t az orm megvalositas generalja, nem neked kell potyogtetni. Ez azert finom tud lenni, ha rdbmst akarsz cserelni. Mi pl lehet, hogy az elkovetkezendo 1-2 evben fogjuk, mert a postgres mar nem nagyon birja.
- (Ez mar nem marketing). Befigyelhet cache is, ami segit tehermentesiteni az adatbazist.
- (Hibernate tud ilyet) Shard. Neha ecceruen tul sok adat van, amivel nem tud mit kezdeni az adatbazis. Marha hasznos dolog am, ez a + reteg egyseges neztet ad nekem.

Ahol szopo az orm:
- Reporting. Nagy, nyakatekert, az adatbazis spec dolgait maximalisan kihasznalo lekerdezesek. Itt az orm csak utban lenne, meg ugy az egesz koncepcio nem illesztheto ide.
- Bulk jellegu adatfeldolgozas. Szukseg lehet mas rendszerekbol nagy mennyisegben, es rendszeresen atvenni adatokat (vagy forditva, tolni kifele). Ilyenkor az orm csak lassit, es zabalja a memoriat.

(csak hogy az ordog ugyvedje legyek kicsit)

Az sql-t az orm megvalositas generalja, nem neked kell potyogtetni. Ez azert finom tud lenni, ha rdbmst akarsz cserelni.

Ez nem az ORM sajatja, barmilyen DB absztrakcios retegnek ez a kovetkezmenye.

Befigyelhet cache is, ami segit tehermentesiteni az adatbazist.

Ez igaz, viszont szvsz a hozzaerto ember csomot tud optimalizalni egy program altal generalt sql kodon, ez meg az erem masik oldala.

Kötözködök én is:
> Ez nem az ORM sajatja, barmilyen DB absztrakcios retegnek ez a kovetkezmenye.
Ha mindenki követné az SQL szabványt, akkor nem kellene minden adatbáziskezelőhöz külön absztraktációs réteg

> Ez igaz, viszont szvsz a hozzaerto ember csomot tud optimalizalni egy program altal generalt sql kodon, ez meg az erem masik oldala.
Az esetek nagy részében egy jó cache többet dob az SQL-en. Ahol meg nagyon gyengén teljesít az ORM, ott ki lehet kézzel optimalizálni az SQL-t.

Ez nem az ORM sajatja, barmilyen DB absztrakcios retegnek ez a kovetkezmenye.

Probaltad mar ezt a barmilyen DB absztrakcios reteget? En meg nem talalkoztam ilyen megoldassal. Kivancsi lennek mit csinalna az Oracle hiearchikus lekerdezeseivel, a Postgre select into temp table utasitasaval, vagy a Mysql select into outfile utasitasaval. Ahhoz, h ez a reteg levalasszon az adatbazistol, kozos nevezot kene keresni, ami meg egy igen csokevenyes sqlhez vezet (ugranak az rdbms specifikus fuggvenyek, es nyelvi kiegeszitesek). Ha belegondolsz az orm is csak egy reszet tudja nyujtani, annak, amit a konkret adatbazis nyujthat.

Ez igaz, viszont szvsz a hozzaerto ember csomot tud optimalizalni egy program altal generalt sql kodon, ez meg az erem masik oldala.

Igen, szejjel lehet hintelni a lekerdezest, a tablat tele lehet szorni indexxel, de a vasnak akkor is van egy maximuma, amit nem lehet tul lepni. Ilyenkor nagyon jol johet, ha van egy cache, ami tehermentesit. Gondoljunk egy forgalmas sitera, masodpercenkent 200 adatbazis lekerdezessel. Nem nehez elhinni, hogy azert jellemzoen nem masodpercenkent valtozik meg egy tabla tartalma. Ilyenkor teljesen felesleges ugyanazt ujra, es ujra lekerdezni. Pl nalunk a cachehit olyan 80%, olyan 800k rekord mellett. Ha ezt beletolnank az adatbazisba (pedig csak szimpla elsodleges kulcs szerinti lekerdezesek lennenek), akkor konnyen lehet, h adatbazisgep kiszaladna a szerverterembol.

CRUDot nem nagyon szoktak optimalizalni, bonyolultabb queryket meg nem db szinten, hanem adatszinten (azaz az entitasokkal dolgozva) van, hogy sokkal egyszerubb megoldani.

a reporting nalunk kulon szoftverrel megy, read-only akkja van a dbhez :) de a native queryket tudja az ember egy JPA-s kornyezetben is hasznalni.

viszont ami nagyon jo dolog: a caching. foleg valami distributed cache cuccal (oracle coherence, vagy terracottanak is van...)