Asi tak. Problémem je především skutečnost, že p. Prýmek považuje použití ORM (což je logické, jinak by aplikace musela zůstat relační) za chybu, ale použití RDB na objektovou doménu mu přijde zcela v pořádku.
Ne. Já považuju za chybu používat jakoukoli knihovnu/framework/abstrakci, která je natolik složitá a neprůhledná, že programátor nedokáže pohledem na kód říct, co vlastně v danou chvíli udělá, a zároveň má potenciálně velmi zásadní vliv na výkon aplikace.
Můžu přidat i osobní zkušenost: v jednom projektu byla komponenta provádějící jakýsi relativně jednoduchý (kontextem parametrizovaný) výpočet nad daty přicházejícímu z vnějšku. Kdyby to dělal člověk ručně, načte si z DB předem cca pět čísel jedním dotazem a pak spustí výpočet, už kompletně bez side effectů, čili snadno paralelizovatelný atd. Ovšem historie tomu chtěla, že danou komponentu psal djangista, čili konfigurace byla uložena pomocí django ORM, načítala se pomocí nějakých magických django objektů a když to bylo v provozu, lámali jsme si hlavu nad tím, proč tak děsně zatěžuje DB. No, nenačítalo se pět čísel, ale nějaké modely, ORM se z nějakého důvodu rozhodl, že k tomu potřebuje i nějaké související hodnoty, takže se ve finále pořádně košatým JOINem načítalo i spousta věcí, které pro výpočet vůbec nebyly potřeba, a to ještě vesele kdykoli jakkoli, třeba uprostřed výpočtu. Nekontrolovatelně. Nádhera...
(Nechci se hádat o to, jestli tahle konkrétní situace jde nebo nejde v Djangu nějak potunit, pointa je v tom, že místo aby se udělala jednoduchá DB s jasnou strukturou a jednoduché SQL dotazy, kterým by každý rozuměl a uměl je ladit, použil se "pohodlný nástroj", který ve finále aplikaci úplně zabil)
334 Odpovědí
47511 Zhlédnutí