Nette database ref/related a ORM
- Pavel Kravčík
- Člen | 1205
Mám tabulku s přibližně 10.000 záznamy a dalších 12 tabulek, které jsou na ní nějak napojené (ref & related ) podle potřeby. Mám to rozchozené na YetORM a funguje to nádherně a skvěle se s tím pracuje. Třeba vypsat jméno klienta ke smlouvě.
$smlouvaEntity = $this->SmlouvaModel();
$klientEntity = $smlouvaEntity->fetchKlientEntity();
echo $klientEntity->jmeno; // Jaroslav Jágr
Tohle funguje skvěle, ale když jsem potřeboval vygenerovat seznam všech smluv do Excelu padalo PHP. První věc byla, že jsem se zbavil PHPExcelu – hrozný žrout paměti. Ale problém zůstával (22.000 dotazů do DB) a trvaly pár minut. Projel jsem strukturu udělal indexy a zlepšení bylo viditelné, ale stále to byly desítky sekund.
Tak jsem se dnes odhodlal a přepsal to do čistého MySQL s left joiny a hodně subquery. A funguje to nádherně a jsem schopen se dostat <1s DB a dvě sekundy generování Excelu.
Měl jsem za to, že Nette s ->ref() dělá to samé, co left join a bude to vycházet přibližně stejně náročně a že ORM vrstva si něco zabere, ale nebude to tolik vidět.
Je tedy lepší se na větší a složitější věci vykašlat s ORM a dělat to „postaru“? Nebo něco dělám špatně?
- Jan Tvrdík
- Nette guru | 2595
Pokud používáš NTDB dobře, tak bys měl mít konstantní počet dotazů. Z toho, cos napsal, těžko usoudit, kde byla chyba.
- Pavel Kravčík
- Člen | 1205
Když jsem koukal do Tracy se to škálovalo:
Výběr smlouvy (0.003), na ní ref1, ref2, ref3 (0.003). A nakonec v Tracy svítilo 22.000 dotazů (což je správně), ale ten čas byl třeba 160.000ms v součtu. Když udělám jeden obrovský dotaz, tak čas je 900ms.
Jde mi spíš o to, jestli ta režie refů a případně ORM může být takhle zrůdná.