my používáme hibernate v informačním systému a musím říci, že s ním nejsou skoro žádné problémy.
Co se týče cacheování v hibernate, doporučuji článek http://www.devx.com/dbzone/Article/29685
Predem reknu ze jsem docela zaujat proto Hibernate, pripada mi ze clovek vymeni ladeni databaze za ladeni Hibernate pro kterou nejsou ani poradne nastroje. Velmi se mi libi iBatis. TopLink jsem nijak nestudoval, pokud o nem napisete budu vdecnt. Ale ted k veci, mam par dotazu: 1) hibernate a spolu umi z gruntu vytvorit strukturu databaze, fajn, ale co kdyz v nove verzi pridam nektery field? Z gruntu vytvaret nejde, u zakaznika v databazi jsou data. Je nejake inkrementalni vytvareni? Jak resite distribuci databazovych zmen na zakaznicke databaze? Existuje nejaky system na verzovani DB?
My to děláme takto:- využíváme možností automatické aktualizace od hibernate - ale neumí položky mazat. Pro kontrolu máme ovšem prográmek, který nám zobrazí seznam změn oproti schématu v hibernate (i nullability) - pokud bude zájem mohu zveřejnit.
- děláme upgrade skripty, které dělají to co hibernate nedokáže (např. ze sloupečku udělat tabulku, apod.). V databázi je uloženo, jakou verzi db teď uživatel má a téměř automaticky se tam pak hází jednotlivé upgrade skripty.
Hibernate neřeší vizualizaci dat. je to jen datová vrstva.2) Jak se resi textove pojmenovani jednotlivych fieldu? V nasem programu mame tabulku nazvu pro kazdy sloupec, Swing client pak jen prevezme tyto nazvy a zobrazi je v tabulce spolecne s hodnotami. Asi se to resi metadaty, ze?
Jak už psal kolega přede mnou - nejde to vyřešit jinak?3) Co specialni fieldy pro jednotlive zakazniky? Je potreba pak udrzovat X verzi mapovacich xmlek a java trid pro jednotlive zakazniky? Nebo jde zvolit nejake "core" co je vsude a na nej nabalovat upravy? Asi nejlepsi by bylo dedeni, toho jsem si ale vsiml jen v JDO.
Řešením je dědění - to má i hibernate. Pokud přímo píšete .hbm.xml tak tam si moc flexibility neužijete. Celá hierarchie jedné třídy je v jednom mapovacím souboru.
Pokud ovšem používáte anotace nebo xdoclet, stačí vlastně přidat nového potomka a podpora je přidaná. Takže pro zákazníky můžete naprosto bez problému mít vlastní zdrojáky.
Možností jak dědit je v hibernate hodně - vše do jedné tabulky, nová tabulka pro rozšiřující položky, každý potomek vlastní tabulka, ...
Skládání dotazů je jedna z nejúžasnějších věcí v hibernate.4) Jak se resi skladani dotazu? Priklad: delam select ze tri tabulek, v JDBC si to vse nactu z resultsetu. Jak se to resi v ORM? Musim udelat novy objekt? Nebo musim vse nacpat do vztahu 1:1 1:N?
Představte si, že máte relaci:
- pokud chtete zjistit kolik je v ní položek tak napíšete:
session.createFilter("select count(*)", objekt.relace());
- pokud chcete jen data, která splňují nějakou podmínku tak:
session.createFilter("where a > 100", objekt.relace());
U návratu hodnot z hibernate máte několik možností:
- vypsat první tabulku a pak procházet další hodnoty (např. vypsat si seznam faktur a při přístupu k položkám faktury se sami donačtou).
- pokud je potřeba něco složitějšího nic nebrání tomuto:
session.createQuery("select tab1, tab2, tab3 from Tabulka1 tab1, Tabulka2 tab2, Tabulka3 tab3");
a v jednotlivých řádcích je pole Object[] o velikosti 3.
stejně tak lze použít:
session.createQuery("select tab1, count(*) tab2 from Tabulka1 tab1 inner join tab1.tab2 group by tab1");
opět pole o velikosti 2.
Teď nechci mluvit o iBatis, to vůbec neznám.5) Jaky maji vykon pri velikostech databazi v 10 GB? Predstava ze si ty data drzi v pameti Oracle, pak ORM framework v cache a pak jeste JVM me beha mraz po zadech. Ale zkusim si tipnout: -Ibatis bude asi ok, tam neni co zkazit. -Hibernate podle toho co jsem cetl zere dost pameti a je narocna na "vytuningovani" -Ruzne implementace JDO nemaji ani moznost tuningovani jako Hibernate, takze jsou nepouzitelne.
K hibernate - pokud jste do teď používali JDBC tak hibernate může být rychlejší. Ve výchozím nastavení se hibernate chová poměrně slušně - záleží na množství objektů, které načtete v jedné transakci.
Sekvenčně jsme procházeli nějakou tabulku a dělali nějaké výpočty. Načetli několik desítek tisíc objektů a začali jsme mít problémy - při volání query se totiž ve výchozím nastavení volá flush(). To se dá vypnout. Ale stejně jsme se nevešli do paměti (přeci jen celá databáze se nám do paměti nevešla). Protože už jsme ty objekty v paměti nepotřebovali - takže jsme nechali vyprázdnit objekty ve first level cache a už je to bez problému.
Second level cache u hibernate nemusíte používat (případně u ní nastavit krátké časy). V paměti v oracle a v JVM se nezbavíte (tak to funguje i u JDBC a i u iBatis).
Takže naše zkušenost je takováto:
- hibernate je výrazně jednodušší na používání než JDBC
- hibernate díky first level cache, second level cache a query cache je výrazně rychlejší než JDBC.
- občas se stane, že je něco pomalé - stačí se na to podívat a doladit to. Obvykle se ale jedná o chybu programátora - např. místo, aby udělal filtr a zjistil počet záznamů tak načte relaci a zavolá size().
Rozhodně nemám pocit, že je hibernate náročný na paměť a je nutné ho tuningovat - jasně má to určitá specifika na které si člověk musí dat pozor.
Takže vaše volba by měla vypadat asi takto:
- IMHO není rozdíl v tom zda používám hibernate 3.x přes hibernate API nebo EJB 3.0 API.
- máte objektový nebo relační přístup k databázi? http://blog.softeu.cz/objektove-relacni-mapovani/
Pokud máte objektový tak rozhodně použijte Hibernate
Pokud relační tak použijte iBatis.
V čem se to liší?
děláte často: update tabulka set a = a +1? -> relační
vyhovuje vám navigační model? -> objektová
Potřebujete
-- Petr Ferschmann SoftEU s.r.o. ----------------------------------- Sady Petatricatniku 31 301 00 Plzen Czech Republic ----------------------------------- Phone: +420 373 729 300 Fax: +420 373 729 301 Cell: +420 775 638 008 |
smime.p7s
Description: S/MIME cryptographic signature
