Vlákno názorů k článku Na co si dát pozor při návrhu databáze? od mikrom - Ja som asi dost konzervativny vyvojar a musim...
-
mikrom (neregistrovaný)
Ja som asi dost konzervativny vyvojar a musim povedat, ze ORM nemam rad. Ak to niekto vyzaduje pouzit, tak nemame s tym problem, ale musime upozornit na nevyhody.
Podla mna je ORM iba urcity modny trend, ktory slubuje vela ale realita je ina ...
Je to podobne ako boli v rokoch 1990 rozne 4GL jazyky. Nieco si v tom rychlo napisal a vygenerovalo to zdrojak v 3GL a skompilovalo.
Problemy vzdy nastali pri rieseni chyb a nestandardnych situacii. Tam si musel debugovat ten vygenerovany kod v 3GL, takze v podstate si sa musel okrem 4GL zaoberat aj 3GL. Cele to bolo na hov...Jedine velmi male vyhody ORM vidim v tom , ze to za mna porobi administrativne veci ako:
try {} catch {}
rs.close();
stmt.close();
conn.close();
zdrojak DAO, ktory vytvorim bude mozno cez ORM o 1/2 kratsiAle ake to prinasa nevyhody ?:
* Som zavisly na cudzom a nestandardnom API/frameworku
* Riesenie chyb je komplikovane - t.j. ked mam v JDBC ten retazec s SQL-prikazom, viem ho 1:1 preniest na SQL-konzolu a verifikovat. Pri ORM je to o dost tazsie oddebugovat a vyriesit to.
* Co mam z toho, ze narobim tie DAO cez ORM rychlo a potom budem v nich dlhodobo riesit chyby, preco nedavaju vysledky ako boli pozadovane ?Je jednoduchsie vysvetlit programatorom, ze maju v JDBC vzdy robit:
rs.close();
conn.close();
ako riesit nasledky pouzitia ORM.Neviem si predstavit, co by to boli za programatori, keby im JDBC robilo problemy, ze nevedia pochopit trochu SQL.
A uplne sa stotoznujem s vyrokom P. Stehule: "Tím, že je programátor odtržený od databáze, tak nemá ani šanci se databáze naučit - pochopit ji, uchopit."
Chceme, aby programator nic nevedel o databazi ? Ja to tak nechcem! Som toho nazoru, ze ked niekto nieco pouzivam musim tomu aj rozumiet. -
L. (neregistrovaný)
To je zase snůška nesmyslů:
> Som zavisly na cudzom a nestandardnom API/frameworku
Takže komunikaci s databází si píšete zvlášť? Nebo používáte "cizí a nestandardní" JDBC? Pokud JDBC, tak čím je cizejší a nestandardnější než třeba Hibernate?
> Riesenie chyb je komplikovane - t.j. ked mam v JDBC ten retazec s SQL-prikazom, viem ho 1:1 preniest na SQL-konzolu a verifikovat. Pri ORM je to o dost tazsie oddebugovat a vyriesit to.
Zkopírovat SQL z debug logu ORM je "kompikované"? I když pro vás možná ano; lecos by to vysvětlovalo.
> Co mam z toho, ze narobim tie DAO cez ORM rychlo a potom budem v nich dlhodobo riesit chyby, preco nedavaju vysledky ako boli pozadovane ?
Pokud píšete DAO s chybami a neumíte je efektivně opravovat, není to problém ORM.
> Tím, že je programátor odtržený od databáze, tak nemá ani šanci se databáze naučit - pochopit ji, uchopit.
A co se programátor naučí a co pochopí o databázi při opakovaném rutinním lopatování dat tam a zpátky? Vůbec nic. ORM framework tyhle nudné a stále stejné části udělá za něj a on se může věnovat těm složitějším věcem. Takže se s ORM frameworkem klidně může naučit víc.
Já dělám projekty, malé i velké, kde se používá ORM framework (Hibernate) a mám i (středně velký), projekt, kde se ORM dělá ručně za použití přes Spring JDBC. A pokaždé když u něj sahám do DAO a musím ty primitivní věci psát ručně si říkám jak jsme byli blbí, že jsme ho na začátku nepostavili nad Hibernate. Na projektech kde Hibernate používáme s tím žádný problém není.
-
j (neregistrovaný)
" ORM framework tyhle nudné a stále stejné části udělá za něj"
Prave ze neudela, a vazne chci videt, jak bude nekdo ladit nejaky query, kdyz libovolna zmena v kodu zmeni i ten dotaz a to klidne i drobna zmena pomerne razantne.Zjevne ty projekty ktere delate jsou pidiprojekty, takze hruba sila to proste nejak utluce.
-
lobo (neregistrovaný)
" ze nevedia pochopit trochu SQL"
kde je hranica medzi 'trochu SQL' a 'vela SQL'?
Ja nechcem aby .NET/Java programator riesil a optimalizoval stored procedure v Oracle - to nie je jeho job."Chceme, aby programator nic nevedel o databazi ? Ja to tak nechcem! Som toho nazoru, ze ked niekto nieco pouzivam musim tomu aj rozumiet."
ja nechcem aby .NET/Java programator riesil specifika databazy XYZ verzie a.b.c
chcem aby dostal data a spravil s nimi co ma -
lobo (neregistrovaný)
"Bohatě bude stačit, když bude znát základní principy, které jsou pro většinu relačních databází stejné a více-méně v čase jsou konstantní."
Zakladne principy pozna ORM velmi dobre - presne na to je to vymyslene. Aby ORM pokrylo genericke, opakovane Select, Insert, Update.
A na specializovane 'ficury' programatorovi zakladne principy prave stacit nebudu.
-
ehmmm (neregistrovaný)
A ja s tim souhlasim. I kdyz musim priznat, ze jedine "ORM", ktere jsem poznal, je DAL ve web2py a SubSonic v .Net. Nejsem zadny velky odobrnik na SQL, ale dost brzo jsem se dostal do situaci, kde moznosti tech dvou vyse uvedenych nestacily. Staci trochu komplikovanejsi select s nekolika joiny a je to v pytli. A pokud se to tvarilo, ze to je OK, tak stejne bylo potreba kontrolovat, jaky z toho vlastne leze SQL dotaz. Takze za nejdulezitejsi vec v techto dvou nastrojich povazuji moznost napsat surovy SQL dotaz.
Ze to pak vysledek namapuje na nejake objekty, to je prima, to nepopiram. Ale to uz je jen takova tresnicka na dortu. Za nejdulezitejsi povazuji, aby to melo dostatecne vyjadrovaci schopnosti a aby to generovalo optimalni SQL dotazy. Bez toho to nejde.
