Doctrine - vhodnost u velkých projekty

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.

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.

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.

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.

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:
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:
Já taky nejsem, jen se ptám :-)

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ť?

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.

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í).

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:
„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.)