Autor Zpráva
Jirin
Profil
Zdravím,
doposud jsem u projektů používal pro přístup k databázi v podstatě přímý přístup přes PDO, pomocí nějakého QueryBulderu (např. Zend_Db_Select) jsem si vytvořil dotaz a zavolal.

Nicméně hodně se mi líbí Doctrine2, na škole jsem dělal s Javou a JPA/Hibernate mě doslova učaroval a tak jsem rád že Doctrine je v podstatě to samé. Výhody jsou jasné, nicméně mám celkem obavy o rychlost či paměťovou náročnost. Provozuejte, případně znáte nějaké větší projekty, které na tom běží? Mám třeba zpravodajský web a v databázo je 100 tisíc článků, samozřejmě u toho spousta komentářů apod. Nedovedu si příliš představit na to nasadit právě ORM. U toho je přeci jen celkem třeba mít vyladěné SQL dotazy a třeba na takovou homepage stačí vytáhnout jen id,titulek a anotaci, pak je tam u článku třeba dalších 10sloupců, který tady nepotřebuju, ale orm mi je stejně vytáhne. A to nemluvě o tom, že tam budou přichycené třeba komentáře, které budou sice lazy loading, ale na homepage chci u každého článku zobrazit počet komentářů takže se budou i tak načítat, a pošle to spoustu dotazů ne?

Zkrátka je dobré ORM nahodit i u větších databázových tabulek?
joe
Profil
Jirin:
Nicméně hodně se mi líbí Doctrine2, na škole jsem dělal s Javou a JPA/Hibernate mě doslova učaroval a tak jsem rád že Doctrine je v podstatě to samé. Výhody jsou jasné

Já teda nevím, asi jsem nějak zaspal dobu, ale pro mě ORM framework nepřináší žádnou výhodu, jako spíš samé nevýhody (i když třeba jen mou neznalostí):

- efektivita (každý webový programátor by měl umět SQL, u ORM nemám kontrolu nad dotazy, nevím jaké sloupce se budou vybírat, nevím jak se dotazy budou vytvářet, ...)
- rychlost (je snažší napsat SQL dotaz, než psát doménové objekty pro každou tabulku a nedej bože zjišťovat, že tam třeba dobře nejde udělat nějaký mnou požadovaný JOIN)
- výkonnost (k čemu tolik kódu kolem, když mi stačí obyčejný dotaz?)
- nutnost učit se a zkoumat něco nového, co zabere dost času

Když už něco dělám, používám dibi. Celkem by mě zajímalo, kde se vzal ten boom, že všichni najednou budem používat ORM :-)

To, jestli se ORM frameworky hodí na velké databáze (1000 řádků v tabulce nerovná se velká databáze), ale neumím posoudit, takže se omlouvám trochu za příspěvek mimo téma.
Str4wberry
Profil
Co se týče výkonu, tak i u čistého SQL se časem možná dostaneme do situace, kdy optimálně napsané dotazy nebudou rychlostně vyhovovat. A bude třeba data kešovat (ať už vytvořit redundantní sloupec pro počet komentářů ke článku nebo kešování HTML výstupu). Takže to nemusí být až takový problém.
Virtus
Profil
Mám zkušenost s ORM na projektu kde je 1 milion návštěv denně ( jedny nejmenované pornostránky ) a je pravda, že na některých stránkách probíhalo i přes 600 dotazů na databázi přes ORM, kvůli rychlosti jsme museli nasadit kešování dat a to hned ve "4" různých keších(Mc, Fc, Rc, "Sphinx") ( pro každou věc se hodilo něco jiného ). Ovšem stále byli ORM rychlejší než pár velkých dotazů viz. níže. (databáze v zabaleném stavu .gz 1,5GB )

Já v ORM vydím spoustu výhod:

- efektivita: nemusím řešit skládání dotazů = udělám míň chyb, a když scháním programátora do firmy, mám menší požadavky, nepotřebuju aby uměl SQL, samozřejmně je to, ale stále výhoda.
- nezávislost: když používám velké dotazy nemůžu obsah většinou dobře kešovat, protože v takových dotazech, většinou vybírám i něco co kešovat nechci, při spoustě jednoduchý selectů si můžu snadno zvolit co chci kešovat a co ne a na jak dlouho.
- výkonnost: spousta malých selectů, je mnohem rychlejší než jeden obrovský select ( nesetkal jsem se situací, kde by to bylo naopak )
- upravitelnost: díky ORM můžu být klidný, když mi někdo přejmenuje sloupec, upraví se jen na jednom místě, protože v kodu místo něj můžu a měl bych použít alias.
- rozšířitelnost: zákazník si vzpomene, že najednou by chtěl kupříkladu k registraci, přidat nějaké další pole pro vyplnění, které chce někde poté zobrazovat, díky ORM nemusím hledat a přeskládávat dotazy pro zobrazení, protože vím, že se mi vždy vyberou všechny sloupce a danou hodnotu budu mít všude, kde tyto data chci vidět.
- kdo se nechce učit měl by přestat programovat.
- uložiště: podle mně největší váhoda ORM. ORM nejsou jen pro databázi, díky ORM můžu snadno a jednoduše změnit uložiště dat třeba na XML soubor nebo cokoliv jiného, jinou databázi atd. a nemusím kvůli tomu refaktorovat celý kód.

Jednu nevýhodu bych taky, ale našel:
- ani při používání ORM se nevyhnete psaní SQL dotazů, obvykle při filtrování dat, kde je potřeba spojit víc jak jednu tabulku a uživatel si může navolit podle čeho chce data filtrovat.
Jirin
Profil
[#2] joe výhody, u mě je to hlavně větší efektivita u programování, větší přehlednost a komplexnost, více tady popsal těch výhod Virtus. A popravdě napsat jako důvod proč ne - "nutnost učit se něco nového" - to je hodně mimo. tímhle přístupem, by se psalo všechno v assembleru ještě:-)

[#4] Virtus Díky, přesně něco takového jsem potřeboval vědět, že to není problém ani u velkých projektů. Popravdě těch 600dotazů, toho se děsím, aby se nedělo. Jasně malé dotazy jsou rychlé, ale přeci jen 600 je šílenost:) Napadlo mě pak i řešeí stylem, na frontendu u těch rizikových věcí, to psat nativně v SQL a administrace, využívat ORM, protože tam ta rychlost zas tak nevadí, ale to není moc ono. Btw mohu vědět jaký ORM jste použili vy?
Virtus
Profil
Bohužel, tyhle ORM nikde nenajdete = naprogramovali jsme si vlastní, tak aby odpovídali našim požadavkům. Zezačátku jsme sice hledali nějaké hotové řešení, ale bohužel jsme nenašli nic, co by se dalo rozumně používat, tj. nedali se rozumně vyjmout samotná ORM z frameworku, byli příliš robustné = uměly toho až zbytečně moc nebo jim naopak zase něco chybělo, většinou kombinace dvou a to v takovém tvaru, že toho uměli hodně, ale ne to co bychom potřebovali.
joe
Profil
Jirin:
:-)

nutnost učit se a zkoumat něco nového, co zabere dost času
Napsal jsem to jen mezi nevýhody, při programování je samozřejmě nutné se učit, ale pokud si srovnám výhody a nevýhody, vůbec se mi učení ORM frameworku nevyplatí (zvlášť pokud na projektu má pracovat třeba někdo další, kdo opět ORM framework nezná, př.: chci JOIN, v SQL dotazu ho napíšu hned, u některého ORM frameworku musím dlouze hledat a někdy zjistím, že to ani tak, jak požaduji nejde). Nic by mě při práci nemělo zpožďovat.

Virtus:
udělám míň chyb, a když scháním programátora do firmy, mám menší požadavky, nepotřebuju aby uměl SQL, samozřejmně je to, ale stále výhoda.
Ten kdo to používá, by měl vědět, jak to funguje, jaké dotazy to generuje a jestli není lepší cesta, takže tento bod neberu moc vážně :-)

protože vím, že se mi vždy vyberou všechny sloupce
Ideální je vybírat jen ty sloupce, které jsou potřeba, je zbytečné například vybírat všechny informace o uživateli, pokud mě zajímá jen jeho e-mailová adresa.

uložiště: podle mně největší váhoda ORM. ORM nejsou jen pro databázi, díky ORM můžu snadno a jednoduše změnit uložiště dat třeba na XML soubor nebo cokoliv jiného, jinou databázi atd. a nemusím kvůli tomu refaktorovat celý kód
je to výhoda, ale kolikrát to kdo bude dělat? :-)
Jirin
Profil
joe:
„nutnost učit se a zkoumat něco nového, co zabere dost času“
Napsal jsem to jen mezi nevýhody, při programování je samozřejmě nutné se učit, ale pokud si srovnám výhody a nevýhody, vůbec se mi učení ORM frameworku nevyplatí (zvlášť pokud na projektu má pracovat třeba někdo další, kdo opět ORM framework nezná, př.: chci JOIN, v SQL dotazu ho napíšu hned, u některého ORM frameworku musím dlouze hledat a někdy zjistím, že to ani tak, jak požaduji nejde). Nic by mě při práci nemělo zpožďovat.

no pravě joiny klasické řeší orm samo, a ještě většinou lazy loadingem:-) je jasné, že když bude join napříč několika tabulkami apod. tak je lepší nativně. Že má pracovat někdo další a neumí ORM, to je taky otázka, třeba v Javě zase neznám nikoho kdoby dělal jinak než přes ORM, ale ok tady jsme v PHP. Nicméně učení nějakých základů ORM, to je na odpoledne...
joe
Profil
Jirin:
Já věřim, že ORM pomůže, když se dobře ovládá, ale zase aby to bylo na jedno odpoledne, to se mi moc nezdá. Válčil jsem s tim v Javě (na škole) nějakou chvíli a moc dobré dotazy z toho nelezly - trvalo i desítek vteřin, než se načetla stránka, při testování s databází s více daty. Ale už se klasickýmu programování nevěnuju, prostě mi to nepřijde moc efektivní :-)

Napsal bys třeba ve tvém ORM takový dotaz, nerýpu, jen se ptám, jestli by ho to umožnilo napsat a nebo bys mo musel vypsat nativně?
Jirin
Profil
[#9] joe předně já nejsem nějakú super znalec ORM, ale myslím, že takový dotaz ORM samo neřeší a musí se sáhnout po dotazovacím jazyku. Myslím, že v doctrine se to pomocé DQL napsat dá
joe
Profil
Jirin:
Já taky nejsem, jen se ptám :-)
pcmanik
Profil
Pre nás neznalých, čo je to vlastne ORM? A aké výhody / nevýhody to prináša a prečo by som sa mal rozhodnúť to používať?
Jan Tvrdík
Profil
pcmanik:
Před pár dny měl o ORM přednášku Martin Štekl pla.nette.org/cs/posobota-48-martin-stekl-orm. Obecně viz např. seriál na Zdrojáku.
Majkl578
Profil
Pokusím se tu vyvrátit některé mýty, které tu zazněly.

[#2] joe:
efektivita (… u ORM nemám kontrolu nad dotazy …)
Opravdu? Na základě čeho tak usuzuješ? Pokud ORM používáš správně a slepě nevěříš, že ORM čte tvou mysl, kontrolu nad dotazy máš, ať už přímo nebo nepřímo.

efektivita (… nevím jaké sloupce se budou vybírat …)
Ano, zrovna tohle se u ORM moc neřeší, je to totiž poměrně složité a ve výsledku to může velmi snadno vést k neefektivnějšímu přístupu než při výběru všeho (což není až tak drahá operace).

efektivita (… nevím jak se dotazy budou vytvářet, ...)
Pokud tebou používané ORM znáš a znáš jeho architekturu, tak to víš.

rychlost (je snažší napsat SQL dotaz, než psát doménové objekty pro každou tabulku …)
Toto je velmi spekulativní. Při objektovém programování stejně potřebuješ záznam (např. uživatele) reprezentovat nějakým objektem a ten tak či onak třídu (někde, nějak) definovat musíš.

výkonnost (k čemu tolik kódu kolem, když mi stačí obyčejný dotaz?)
Kvůli objektovému přístupu. Co nazýváš obyčejným dotazem? Volání mysql_query a následný výpis v cyklu? To opravdu není objektový přístup.

nutnost učit se a zkoumat něco nového, co zabere dost času
Neplatný argument, který lze aplikovat na cokoliv (věř nebo ne, i na samotné SQL).

Celkem by mě zajímalo, kde se vzal ten boom, že všichni najednou budem používat ORM
Možná to bude tím, že objektové programování je dnes jakýsi trend (oprávněně).

[#4] Virtus:
Mám zkušenost s ORM na projektu kde je 1 milion návštěv denně ( jedny nejmenované pornostránky ) a je pravda, že na některých stránkách probíhalo i přes 600 dotazů na databázi přes ORM, kvůli rychlosti jsme museli nasadit kešování dat a to hned ve "4" různých keších
A seš si jistý, že to nebyla chyba programátorů, kteří pouze neuměli použití ORM optimalizovat? Velmi pravděpodobně to tak totiž bylo/je. 1:N asociace umí poměrně snadno navýšit počet dotazů, ač jednoduchých a řešení je kolikrát triviální -- nepoužívat lazy kolekce, ale extra lazy popř. eager.

efektivita: nemusím řešit skládání dotazů = udělám míň chyb, a když scháním programátora do firmy, mám menší požadavky, nepotřebuju aby uměl SQL, samozřejmně je to, ale stále výhoda.
Upřímně řečeno, teď už plně chápu, proč máte na webu 600 a více dotazů. S tímhle přístupem hodně štěstí a úspěchů při nakupování nového výpočetního výkonu (místo hledání kvalitních programátorů). :)

výkonnost: spousta malých selectů, je mnohem rychlejší než jeden obrovský select ( nesetkal jsem se situací, kde by to bylo naopak)
Zajímavé tvrzení. V praxi to ale takto nefunguje, ono totiž i položení jednoduchého dotazu obnáší další režii. 100 jednoduchých selectů podle primárního klíče bude určitě pomalejší než jeden dotaz na výběr všech najednou.

uložiště: podle mně největší váhoda ORM. ORM nejsou jen pro databázi, díky ORM můžu snadno a jednoduše změnit uložiště dat třeba na XML soubor nebo cokoliv jiného, jinou databázi atd. a nemusím kvůli tomu refaktorovat celý kód.
Tak toto opravdu není pravda. ORM, už ze svého názvu, slouží pro práci s relační databází a za XML úložiště bys jej vyměnil jen velmi těžko. Na jiná úložiště se používají jiná mapování, například ODM pro dokumentové databáze nebo OXM pro XML.

Jednu nevýhodu bych taky, ale našel:
- ani při používání ORM se nevyhnete psaní SQL dotazů, obvykle při filtrování dat, kde je potřeba spojit víc jak jednu tabulku a uživatel si může navolit podle čeho chce data filtrovat.
Opravdu je to nevýhoda? ORM se nikdy netvářilo jako nástroj, který člověka zbaví potřeby znalosti/používání SQL.

[#6] Virtus:
Bohužel, tyhle ORM nikde nenajdete = naprogramovali jsme si vlastní, tak aby odpovídali našim požadavkům.
Aha, možná zde vznikl onen problém se 600 dotazy na stránku. Téma ale je o Doctrine.

[#7] joe:
Ideální je vybírat jen ty sloupce, které jsou potřeba, je zbytečné například vybírat všechny informace o uživateli, pokud mě zajímá jen jeho e-mailová adresa.
To záleží na různých faktorech, například na tom, jak je daná operace drahá. Zrovna výběr všech informací o uživateli nebude o tolik náročnější než vybrání pouze jména (a o pár řádků níže např. další dotaz na výběr pouze e-mailu).

[#8] Jirin:
Nicméně učení nějakých základů ORM, to je na odpoledne...
To není, zejména pro člověka, který problematice pořádně nerozumí.

[#9] joe:
trvalo i desítek vteřin, než se načetla stránka, při testování s databází s více daty
A určitě to byl problém Hibernate a ne databáze (chybějící indexy, …) nebo Javy samotné, která není zrovna dvakrát rychlá?

Napsal bys třeba ve tvém ORM takový dotaz, nerýpu, jen se ptám, jestli by ho to umožnilo napsat a nebo bys mo musel vypsat nativně?
Takový dotaz je poměrně atypický, tudíž nejspíš ne, dalo by se ale použít obdobné řešení standardnějším zápisem (WHERE (ID_polozky = 11043 AND druh = 'kniha') OR (ID_polozky = 9443 AND druh = 'film')). Případně lze sáhnout po nativním SQL, jehož výsledek se posléze namapuje na pole/objekty.

------

Osobně Doctrine 2 používám a splňuje má očekávání. Chci psát aplikace objektově, využívající relační databázi, a k tomu slouží právě ORM.

[#1] Jirin:
mám celkem obavy o rychlost či paměťovou náročnost
Je nutné počítat s určitým overheadem, jelikož mapování na objekty má nějakou režii. Nicméně při správném použití to není nic až tak závratného, na čem by se nedala postavit velká aplikace.

Mám třeba zpravodajský web a v databázo je 100 tisíc článků, samozřejmě u toho spousta komentářů apod. Nedovedu si příliš představit na to nasadit právě ORM.
Z jakého důvodu? A jak vlastně souvisí velikost databáze s ORM?
Osobně v tom nevidím problém, sám mám několik webů postavených nad Doctrine, kde databázové tabulky mají statisíce řádků a fungují.

U toho je přeci jen celkem třeba mít vyladěné SQL dotazy a třeba na takovou homepage stačí vytáhnout jen id,titulek a anotaci, pak je tam u článku třeba dalších 10sloupců, který tady nepotřebuju, ale orm mi je stejně vytáhne.
Tak si:
a) napíšeš dotaz, který ti vrátí pouze tyto údaje, nebo
b) použiješ keš.

A to nemluvě o tom, že tam budou přichycené třeba komentáře, které budou sice lazy loading, ale na homepage chci u každého článku zobrazit počet komentářů takže se budou i tak načítat, a pošle to spoustu dotazů ne?
Co si máme představit pod pojmem přichycené?
Asociace v Doctrine jsou trojího druhu, EAGER (načítané vždy), LAZY (u 1:N/M:N se vytáhnou se primární klíče a vytvoří proxy objekty) nebo u 1:N/M:N vazeb EXTRA_LAZY (netahá se nic, vazba je zcela neinicalizovaná). Osobně si myslím, že EXTRA_LAZY je často velmi rozumná volba, zejména pokud má asociace mnoho záznamů a/nebo není často používaná.

Zkrátka je dobré ORM nahodit i u větších databázových tabulek?
Co je větších? 100 tisíc řádků? 1 milion řádků? 100 milionů řádků?
Ono bude záležet na různých faktorech. Zejména na kvalitě návrhu databáze/modelu (tj. např. dodržení normálových forem) a na povaze (ne na vše se ORM hodí).
Virtus
Profil
Majkl578:
Upřímně řečeno, teď už plně chápu, proč máte na webu 600 a více dotazů. S tímhle přístupem hodně štěstí a úspěchů při nakupování nového výpočetního výkonu (místo hledání kvalitních programátorů). :)
Z ekonomického hlediska je v dnešní době lepší nakoupit výpočetní výkon, než měsíčně platit "velkou" mzdu, kvalitním programátorům, ale asi v tomhle směru nejsem dost objektivní, protože projekty, na kterých pracuju, se neprodávají veřejnosti, tudíž interně v nákupu výpočetního výkonu nevidím problém. Nehledě nato, že kvalitních programátorů je málo a špatně se hledají.

Aha, možná zde vznikl onen problém se 600 dotazy na stránku. Téma ale je o Doctrine.
Mně spíš příde, že téma je otom, zda je dobré ORM nahodit i u větších databázových tabulek, než konkrétně o Doctrine.

Se zbytkem více méně souhlasím, protože už sem asi moc navyklí na firemní framework, o který jsem se při svích tvrzeních opíral, aneb každý méme jiné zkušenosti. Každopádně, patřím mezi zastánce ORM a tudíž nevidím žádný problém, proč je napoužívat na jakém koliv projektu, jediný co mně napadá, kde se ORM nehodí jsou importy mezi databázema, když potřebuju starou databázi, nějakého projektu převézt do nové databáze, kde jsou data ukládány jinak (v jiných sloupečkách, v jiném formátu, atd.), tj. nerovná se o kopii původní DB, v tomhle směru jsou ORM opravdu několikanásobně pomalejší než přímé dotazy.
Jirin
Profil
Majkl578:
Předně díky za hutný komentář.

[#8] Jirin:
„Nicméně učení nějakých základů ORM, to je na odpoledne...“
To není, zejména pro člověka, který problematice pořádně nerozumí.
Měl jsem opravdu na mysli jen základy (je mi jasné, že nebude ihned orm master), ale je pravda, že asi člověk, který nemá ponětí ani o oop, tak u něj to tak nebude.

[#1] Jirin:
„Mám třeba zpravodajský web a v databázo je 100 tisíc článků, samozřejmě u toho spousta komentářů apod. Nedovedu si příliš představit na to nasadit právě ORM.“
Z jakého důvodu? A jak vlastně souvisí velikost databáze s ORM?
Osobně v tom nevidím problém, sám mám několik webů postavených nad Doctrine, kde databázové tabulky mají statisíce řádků a fungují.
„U toho je přeci jen celkem třeba mít vyladěné SQL dotazy a třeba na takovou homepage stačí vytáhnout jen id,titulek a anotaci, pak je tam u článku třeba dalších 10sloupců, který tady nepotřebuju, ale orm mi je stejně vytáhne.“
Tak si:
a) napíšeš dotaz, který ti vrátí pouze tyto údaje, nebo
b) použiješ keš.

V podstatě tohle souvisí spolu obojí. Jde mi o to, že budu přenášet zbytečně několik dalších sloupců a třeba i celý článek textový, který je fakt zbytečný apod. Ano mohu použít vybání konkrétních sloupců v doctrine, ale tím si mohu zadělat problémy s nekonzistencí zase. Cache je samozřejmě dobrá věc, ale zrovna u zpravodajského webu ne všude dobře použitelná. Pokud lidi komentují i několik komentářů za minutu a budou dotazy stejně trvat dlouho tak cache moc význam nemá.


„A to nemluvě o tom, že tam budou přichycené třeba komentáře, které budou sice lazy loading, ale na homepage chci u každého článku zobrazit počet komentářů takže se budou i tak načítat, a pošle to spoustu dotazů ne?“
Co si máme představit pod pojmem přichycené?
Asociace v Doctrine jsou trojího druhu, EAGER (načítané vždy), LAZY (u 1:N/M:N se vytáhnou se primární klíče a vytvoří proxy objekty) nebo u 1:N/M:N vazeb EXTRA_LAZY (netahá se nic, vazba je zcela neinicalizovaná). Osobně si myslím, že EXTRA_LAZY je často velmi rozumná volba, zejména pokud má asociace mnoho záznamů a/nebo není často používaná.

přichycené, prostě budu mít tabulku clanky a komentare. a chci vypisovat id, titulek a anotaci článků a k tomu ještě vypisovat počet komentářů. Budu tedy mít u entity clanky vazbu na kolekci komentářů. No a pokud bude klasicky LAZY, tak při zavolaní count($article->comments) se mi dotáže databáze ne? A jestliže těch ččlánku na homepage bude 20, tak mám 20 dotazů na dtb navíc ne? Samozřejmě je řešením nějaké předpočítávání počtu komentářů a vytáhne se to tak automaticky bez problémů, ale teď to řeším, jestli chápu dobře ten princip.


„Zkrátka je dobré ORM nahodit i u větších databázových tabulek?“
Co je větších? 100 tisíc řádků? 1 milion řádků? 100 milionů řádků?
Ono bude záležet na různých faktorech. Zejména na kvalitě návrhu databáze/modelu (tj. např. dodržení normálových forem) a na povaze (ne na vše se ORM hodí).
řádově statisíce, ale nemám na mysli nějaký tabulky, kde jsou jen integer, ale berme právě příklad tabulku s články, řekněme o dvaceti sloupcích.
Majkl578
Profil
Jirin:
Budu tedy mít u entity clanky vazbu na kolekci komentářů. No a pokud bude klasicky LAZY, tak při zavolaní count($article->comments) se mi dotáže databáze ne? A jestliže těch ččlánku na homepage bude 20, tak mám 20 dotazů na dtb navíc ne? Samozřejmě je řešením nějaké předpočítávání počtu komentářů a vytáhne se to tak automaticky bez problémů, ale teď to řeším, jestli chápu dobře ten princip.
Zrovna Doctrine takhle nefunguje.
Uvádíš typický případ 1:N vazby. Pro tu existují, jak jsem uvedl výše, tři druhy načítání, tedy EAGER, LAZY a EXTRA_LAZY.
EAGER načte všechny komentáře ve chvíli, kdy bude načten článek.
LAZY si zjistí ID příslušejících komentářů a vytvoří proxy třídy, tedy bez dat, pouze naplněné primárními hodnotami. Samotná data dotáhne až ve chvíli, kdy k nim bude přistupováno, jinak řečeno, ve chvíli, kdy přistoupíš k některému datovému atributu, načte se celá entita. Při provedení count se dotaz neprovede, protože kolekce je již inicializovaná v paměti (byť pouze proxy třídami). Nejsem si jistý, jestli se daná ID načtou pomocí left/inner joinu, ale myslím, že nikoliv. Toto je defaultní chování.
EXTRA_LAZY si nic nezjišťuje a žádné proxy třídy nevytváří. Při provedení count (nebo contains/slice/add/offsetSet) je proveden dotaz přímo na databázi, ale entity nejsou ani teď načteny. Entity jsou načteny až když je kolekce použita pro jejich čtení (např. iterace).

Osobně nejčastěji používám EXTRA_LAZY kolekce, právě z výkonnostních důvodů.

Vše je poměrně srozumitelně popsáno v dokumentaci.

nemám na mysli nějaký tabulky, kde jsou jen integer, ale berme právě příklad tabulku s články, řekněme o dvaceti sloupcích
To nehraje až takovou roli. Důležitá je mohutnost konkrétní asociace. Pokud bych například měl 1:N asociaci jazyk <-> článek, zcela jistě by byl s LAZY problém, nicméně s EXTRA_LAZY nikoliv. (Pomiňme teď fakt, že dělat takovou vazbu obousměrnou nedává moc smysl, ale jen pro příklad.)
Jirin
Profil
Díky za upřesnění, já měl za to, že LAZY funguje jako EXTRA_LAZY.

Vaše odpověď

Mohlo by se hodit


Prosím používejte diakritiku a interpunkci.

Ochrana proti spamu. Napište prosím číslo dvě-sta čtyřicet-sedm: