Srovnání – NDB, Doctrine, Nextras ORM, NotORM

Budu potřebovat pokrýt hodně aplikací, takže nic nízkoúrovňového vzhledem k časovým možnostem. Jelikož jednotlivé moduly budou používat různí klienti, tak se můžou záznamy pohybovat ve stovkách, ale i statisících, takže je super něco optimalizovaného pro obsáhlá data, ale nějak extrémně nezpomalující ty menší.
Jestli se používá orm nebo relační přístup mi je jedno, ale možnost kombinace by asi též nebyla špatná.
Podpora mi stačí u MySql a testy samozřejmost.
Abych upřesnil tu rychlost, tak pár procent rozdíl nehraje roli, spíš mě zajímají propastné rozdíly. Též propastné rozdíly v memory managementu a v případě orm v počtu generovaných dotazů.

Pro mě je i titulek stránky komponenta, takže ne, že by mi doktrína nevyhovovala, ale bude ze všech nejpomalejší.

Čisté PDO má spoustu nedostatků a těžko se odhalují.

Napiš si vlastní drobnou aplikaci pomocí daných ORM/DBALu. Vezme ti to dva dny, ale budeš mít zásadně lepší představu. Něco typu https://github.com/…ras/orm-demo. + Zkus nějaký custom SQL, jak se v daných ORM píší.

Já samozřejmě vím, proč to Nextras ORM dělám, takže k tomu těžko můžu mít objektivní pohled, ale zásadně se vymezuji, že orm má nějakou „fylozofii“ ;-) ;-)

Editoval hrach (16. 2. 2017 8:35)

@Mabar Ty benchmarky nejsou moc vypovidaji, dulezite je, jak bezny usecase generuje SQL; dale jestli umi optimized loading (aka konstantni pocet dotazu pri zanorenych cyklech) automaticky, nebo to musis rucne napsat , etc.

A to už sis zkusil napsat napsat nějakou app v Doctrine? ;)

Pokud programuji objektově – modeluji, rozděluji zodpovědnosti, a následně implementuji, je velice vhodné mít třídy pokud možno nezávislé na infrastruktuře. Toto Doctrine s určitými ústupky umožňuje. Tím, že při použití Nextras\Orm musí každá entita implementovat IEntity , má okamžitě, wow, 20 zodpovědností. Mají tyto zodpovědnosti na mojí doménové vrstvě smysl? No, pro mě ne.

Hodně lidí začíná ze špatného konce – tady mám nástroje, a podle toho, co mi umožní, budu programovat. Pojďme na to z druhé strany. Co potřebuji? Potřebuji objekty? Jako opravdu? Anebo je jsou mi objekty pendrek a potřebuji efektivní čtení? Anebo potřebuji mít aplikaci rychle nabouchanou?

ORM řeší probém – potřebuji pracovat s objekty a potřebuji je ukládat do relační databáze. Pokud jeden z těchto problémů nemám, ORM nepoužiju.

Editoval Svaťa Šimara (16. 2. 2017 13:27)

@Mabar Jak to prosím funguje objektově? Mám základní třídu Users, jakým způsobem tuto třídu rozšiřuješ dalším modulem?

Píšeš tady o tabulkách a sloupcích, nikoliv o zodpovědnostech a chování.

Zeptám se ještě jednou – opravdu používáš a potřebuješ používat objekty?
Pokud ne, ORM je nesmyslný nástroj.

Tvrdím, že pokud nepotřebuje objekty, ať je nepoužívá

No a to je právě to, na čem se neshodneme. Já taky nepotřebuji objekty, ale psát bez objektů pro mě znamená víc práce, většinou horší testovatelnost apod. Co to vůbec znamená, potřebovat objekty? Přijde, že ho prostě zcela zbytečně odrazuješ od toho, aby si s ORM zkusil nějaký projekt napsat.

Dobře, teď jsi mě dostal, k čemu jsou prosím taky objekty dobré (než jen k OOP)?

Třeba k funkcionálnímu programování. Nebo k tomu, že si tak snadno můžeš předávat balík užitečných funkcí nebo hodnot. Nebo jako alternativa k asociativnímu poli, kterou jde lépe staticky analyzovat, protože má jasnou strukturu. Nebo jako nástroj pro snížení počtu parametrů funkce (protože část parametrů přesuneš do konstruktoru a nemusíš je uvádět při každém volání).

@JanTvrdík Super reakce, možná jsi přehlédl pár otázek, můžeš prosím odpovědět i na ně? Projistotu je sem zopakuji.

To jako lidi, co dřív objekty nepoužívali, s nimi nemůžou začít?

Zřejmě dochází k nedorozumění, můžeš mi prosím ukázat, kde přesně tvrdím, že s objekty nemohou lidé začít?

Stejně tak prakticky nikdo nepotřebuje používat objekty, ale to neznamená, že by z využití objektů netěžili.

Docela odvážné tvrzení, že prakticky nikdo nepotřebuje používat objekty. Z jakých zkušeností a zdrojů čerpáš?

Co to vůbec znamená, potřebovat objekty? Přijde, že ho prostě zcela zbytečně odrazuješ od toho, aby si s ORM zkusil nějaký projekt napsat.

Už si připadám jako Goebbels. Nejdříve musím mít problém – přemýšlím o chování, modeluji objektově. Tento model potřebuji implementovat, pak použiji objekty. Pokud nepřemýšlím objektově, nemodeluji objektově, nepoužiji objekty.
Odrazuji ho od používání objektů, pokud nepřemýšlí objektově. V takovém případě jsou objekty nesmyslné.

Dobře, teď jsi mě dostal, k čemu jsou prosím taky objekty dobré (než jen k OOP)?

Třeba k funkcionálnímu programování.

Není vhodnější použít funkcionální jazyk než objektový?

Nebo k tomu, že si tak snadno můžeš předávat balík užitečných funkcí nebo hodnot.

K tomu stačí pole, nebo struktura v jiných jazycích.

Nebo jako alternativa k asociativnímu poli, kterou jde lépe staticky analyzovat, protože má jasnou strukturu. Nebo jako nástroj pro snížení počtu parametrů funkce (protože část parametrů přesuneš do konstruktoru a nemusíš je uvádět při každém volání).

Pokud už jsem nucen použít PHP, tak souhlas.

Pro mě to byl strašný mind-switch – z relačního do objektového.

Tvůj život musí být strašné utrpení, switchovat z php do mysql, pak composer v cli, tu git, tu javascript, tu html, tu css, (tu kabel). Vytváříš tu představy o nějakých zásadních problémech, kterém jsem nikdy osobně neměl, a myslím, že běžný programátor taky nemá.

@Mabar Děkuji za podnětnou reakci

Doporučovat funkcionálního programování na jakýkoli strukturální systém v případě, že člověk nepoužívá objekty je absolutní blbost.

Uznávám chybu. Ve funkcionálním programování se nevyznám, proto ho nemám co doporučovat. Zkusím se vyjádřit vhodněji – Zamyslete se prosím, jakým způsobem modelujete, pokud to není objektový model, nepoužívejte OOP, ale něco jiného. Co? Třeba php funkce a pole, ale určitě najdete i vhodnější nástroje. :-)

Když se člověk podívá na to, jaké příspěvky píšeš, tak očividně s radostí shazuješ všechny projekty, co nejsou doctrine.

V úvodním příspěvku jsem se vyjadřoval kladně k PDO. Potřebuji pokládat dotazy, které mi vrací pole? Použiji PDO.
Kritika LeanMapperu a Nextras\ORM je založena na tom, že doménové objekty musí splňovat dost drsné rozhraní, které nesouvisí s doménovou logikou.

Objekty. I když mám i pro titulek stránky komponentu, tak to neznamená, že potřebuji ORM. Tohle tvrzení je absolutní blbost. ORM (object-relation mapping) mě jen odstíní od přemapovávání mezi relační databází a objektovým systémem.

Co si prosím představuješ pod pojmem komponenta? Já mám za komponentu něco, co jde vykreslit. Nikoliv doménový objekt, který obsahuje logiku. Tady dochází zřejmě k nedorozumění v názvosloví.

Tu relační databázi tam máš vždycky, jelikož je objektová databáze v praxi na většinu use cases nepoužitelná.

Good point. Ne. Toto není pravda. Pro některé operace mám připravenou čtecí dokumentovou databázi. Tato databáze obsahuje denormalizovaná data přesně tak, jak je potřebuji pro čtení. Žádné relace, ale krásně připravené dokumenty.
Časem se mi ukazuje, že bych chtěl mít pro celý web čtecí model připravený přesně tak, jak jej bude aplikace zobrazovat. Ta rychlost, ta přehlednost, hm…

Ale většina z nás má klienty, které to css a javascript zajímá. A ať pracuješ v týmu nebo samostatně, tak to musíš znát. Sám neuděláš nic a v týmu se nikdy nedostaneš k optimu.

Chápu že toto je realita full stack programátorů. Ano, pracuji v týmu a CSS a JS vůbec neřeším. Ve velké části aplikace neřeším ani HTML, protože jedeme RESTkou. Ale ano, někde musím připravit šablony – tam vypíšu proměnné oddělené <br> a kodér se stará o zbytek. Takže ani HTML vlastně neznám.

Takže to, že nepoužíváš composer…

Budu citovat sám sebe „využívám na denní bázi jenom php a git“

Napsal jsem to takto schválně, protože composer používám jednou za… měsíc, dva… cca. A v době kdy přidávám knihovny, aktualizuji je a pročítám changelogy, tak neřeším php ani git.

@Šaman Díky za odpověď

Ani ta Doctrine tě neostíní od relační databáze dokonale.

Tady si zřejmě nerozumíme. Celou dobu tvrdím, že musím mít objektový návrh a musím jej chtít persistovat do relační databáze. Pak teprve použiju ORM. Musím mít důvod persistovat objekty do relační databáze. Proč? Protože v relační databázi se skvěle vyhledává, spojuje nesouvisející. Rozhodně netvrdím, že se chci odstínit od relační databáze. Nechci se od ní odstínit, chci pořád využívat její výhody.

Jindy je třeba potřeba rozbít objekt na dva, ačkoliv to z hlediska doménové logiky nedává smysl…

I čtení je doménová logika, takže pokud potřebuji číst zvlášť jenom podčást objektu, mám špatně už objektový návrh. A to i bez optimalizací kvůli datům.

A pokud použiješ objektovou databázi, tak jistě víš, že bude opravdu oříšek efektivně získat všechny anglické autory, kteří vydali alespoň dvě knihy během první světové války, nebo jejichž knihy mají nadprůměrné hodnocení.

Souhlas, ale co jsem chtěl v sekci o objektové databázi předat je myšlenka čtecího modelu. Ve čtecím modelu mám data přesně tak, jak je chci zobrazit. Takže pokud budu mít na stránce boxíx s přesně těmato informacema, proč je nemít ve čtecím modelu předpočítaná? A tento čtecí model aktualizovat při stanovených událostech.

Ale chápu, kam míříš, co tady popisuješ, je typický use-case pro relační databázi ;-)

mám plnohodnotné objekty (entity v E-R diagramu)

Toto slovní spojení nechápu, můžeš ho prosím rozvést?
Protože objekty jsou instance tříd. Nemají spojitost s entitami v E-R diagramu.

Asi používám Doctrine nějak jinak, než si představuješ Ty. SQLka (resp. DQL pomocí QueryBuilder) píšu ručně na veškeré čtení. Takže s trochou snahy se dá udělat fulltext vyhledávání – bude potřeba vytvořit buď Native Query nebo přidat syntaxi do DQL. Taky se pro časté čtení nehodí hydratovat entity.

Doctrine pomáhá prostě v zápisu:

1. Vytáhnu si pomocí Doctriny z DB entity
2– Provedu use case
3. Persistuju entity

Ale hlavní benefit Doctrine tkví v tom, že mám objekty bez závislosti na infrastruktuře (skoro, kolekce si hydratuje Collection). Takže jsem schopný doménovou logiku vyvíjet bez databáze. Testovat. A tak :-)

@DavidKlouček Nemyslím, že to je blbost. Něco podobného jsem udělal.