Nette database ref/related a ORM

Upozornění: Tohle vlákno je hodně staré a informace nemusí být platné pro současné Nette.
Pavel Kravčík
Člen | 1205
+
0
-

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
+
0
-

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
+
0
-

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á.