Čímž jsme se efektivně dostali na půdu čistého SQL a namapování dat do nějaké vyšší struktury.
mozna u 1% dotazu, u zbytku vam to usetri praci. Mel byste priklad takoveho dotazu, ktery nejde napsat v querybuilderu?
Typicky složité updaty, případně zřetězené s WITH.
Stačí mít UPDATE ... SET sl1.subquery.sl1, ..., FROM (SELECT ...) AS subquery, ...
Jakmile do toho subquery potřebujete zahrnout window funkce, řazení přes kostku, ..., tak už docela jistě narazíte. Pokud nenarazíte, bude ten zápis stejně nečitelný.
Zrovna tyto operace chcete přenést do databáze, protože zrovna na nich je řádově efektivnější.
databaze je vetsinou uzke hrdlo aplikace, aplikacni kod lze snadno horizontalne skalovat.
Což považuji za tradovaný omyl, pramenící z neschopnosti využívat vlastností SQL.
Prakticky nikdy nenaleznete případ, kdy by byla aplikace výkonnější, než databázový stroj. I ideálně napsaný aplikační kód bude mít hendikep ve zbytečném síťovém provozu a nárocích na další prostředky.
Situací, kde je nevyhnutelná potřeba horizontálního škálování, je tak málo, že je dost nepravděpodobné, že by se s tím programátoři setkávali. Obvykle je horizontální škálování z nouze ctnost.