Příspěvky

241

Vývoj / Re:Rada při návrhu db tabulek

« kdy: 28. 06. 2021, 09:40:22 »

Já bych se v tomhle případě Mirka zastal.

Silhavy neni zadny developer, ani backend ani frontend, vy podle vseho take ne.

242

Vývoj / Re:Rada při návrhu db tabulek

« kdy: 28. 06. 2021, 05:02:39 »

Pokud chcete tabulky se strankovanim + razenim, tak je MUSITE vyselektovat jednim dotazem, ma to tak vetsina webu, ORM se k tomu pouziva bezne.

Selektovani dat v cyklu je antipattern, s ORM nema nic spolecneho.

243

Vývoj / Re:Rada při návrhu db tabulek

« kdy: 28. 06. 2021, 01:17:37 »

naopak, pokud potrebujete v aplikaci vykreslovat nejake tabulky a v ruznych tabulkach se opakuji sloupce, treba jen s malou obmenou, s ORM muzete snadno sestavovat dotazy DRY zpusobem.

treba v Djangu staci k dotazu pridat

Kód: [Vybrat]

.annotate(sloupec_vysledku=funkce_generujici_sql(parametry))

ten kod muze pridat treba slozity join, CASE konstrukci a podobne

VZDY to vygeneruje validni SQL.

v cistem SQL je tohle oser s lepenim dotazu z retezcu, proto se casteji volaji dotazy v cyklu

ocenil bych, kdyby se do diskuze o ORM zapojovali lidi, kteri s ORM pracuji. Vy tu jen papouskujete myty, ktere znate z doslechu.

244

Vývoj / Re:Rada při návrhu db tabulek

« kdy: 28. 06. 2021, 01:02:17 »

V případě užití ORM se tomu prakticky vyhnout nedá.

mytus, to platilo mozna pred dvaceti lety u nejakych primitivnich javovskych ORM.

245

Vývoj / Re:Rada při návrhu db tabulek

« kdy: 28. 06. 2021, 00:55:33 »

Za provadeni dotazu v cyklu nemuze ORM. Uplne stejne muzete v cyklu volat nejakou funkci, ktera dotazuje databazi i bez ORM.

246

Vývoj / Re:Rada při návrhu db tabulek

« kdy: 27. 06. 2021, 22:33:16 »

Databáze jsou úzké hrdlo, protože spousta lidí je neumí používat. Dejte mi příklad, kde je úzkým hrdlem databáze, můžeme si k tomu napsat.

temer libovolna webova aplikace s vetsim provozem a vypnutym cachovanim, treba i tohle forum, kdyby tu bylo vetsi mnozstvi diskuteru. Netvrdim, ze preneseni aplikacni logiky na server ma vzdy nejaky zasadni negativni vliv, ale urcite neplati opak (databaze je vzdy efektivnejis) jak tvrdite vy.

247

Vývoj / Re:Rada při návrhu db tabulek

« kdy: 27. 06. 2021, 22:22:11 »

Jinak třeba přenos dat mezi klientem a serverem má také dost velkou režii - lokální výpočet může být v nanosec, výpočet na aplikačním serveru s execem jste v nejlepším případě na desetinách milisec.

pridani validaci na klientu naopak snizi prenos dat mezi klientem a serverem (nevalidni data se na server vubec nedostanou).

jinak databaze je uzke hrdlo temer u vsech aplikaci s trochu vetsim trafikem.

248

Vývoj / Re:Rada při návrhu db tabulek

« kdy: 27. 06. 2021, 21:59:55 »

Čí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ý.

prave v praci s poddotazy vyniknou vyhody ORM a query builderu, muzete snadno dotaz skladat z mensich celku.

249

Vývoj / Re:Rada při návrhu db tabulek

« kdy: 27. 06. 2021, 21:46:26 »

Čí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?

250

Vývoj / Re:Rada při návrhu db tabulek

« kdy: 27. 06. 2021, 21:42:36 »

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.

251

Vývoj / Re:Rada při návrhu db tabulek

« kdy: 27. 06. 2021, 21:37:44 »

Trochu mi uniká výhoda. Místo toho abych napsal exec("SELECT ..."), tak píšu cn.select("tablename").where(...)

Ono to obvykle naráží i na to, že takový query builder neumí celý dialekt dané databáze (nebo její verze), takže to stejně skončí u exec("SELECT ...").

query buildery umoznuji kombinovat raw SQL, takze umi cokoliv

252

Vývoj / Re:Rada při návrhu db tabulek

« kdy: 27. 06. 2021, 21:36:11 »

Kdyz uz mate ORM schema, muzete z neho automaticky generovat webove formulare, REST API, GraphQL api. ORM umoznuje pridani informaci, ktere SQL nepodporuje, treba ruznych pokrocilejsich validaci.

253

Vývoj / Re:Rada při návrhu db tabulek

« kdy: 27. 06. 2021, 21:30:14 »

doporucuji se podivat na http://docs.peewee-orm.com/en/latest/ , coz je podle me ORM udelane spravne, pripadne SQLAlchemy

Trochu mi uniká výhoda. Místo toho abych napsal exec("SELECT ..."), tak píšu cn.select("tablename").where(...)

Tyhle query buildery jsou asi bezproblémové (je to jen manipulace se stringama), jen mi to příšlo jako řešení, aby se vlk nažral (v aplikaci se mi nevyskytuje SQL) a koza zůstala celá (v podstatě programátor musí napsat kompletní SQL).

to neni querybuilder, je to plnohodnotne ORM, ale umoznuje jit o uroven niz. Doporucuji se podivat na praci s relacemi (nemusite psat stale dokola podminky joinu jako blbec), praci s migracemi atd.. Navic ty dotazy pisete v Pythonu, mnohem jednodussi generovani dynamickych dotazu nez lepeni ze stringu.

254

Vývoj / Re:Rada při návrhu db tabulek

« kdy: 27. 06. 2021, 21:10:43 »

doporucuji se podivat na http://docs.peewee-orm.com/en/latest/ , coz je podle me ORM udelane spravne, pripadne SQLAlchemy

255

Vývoj / Re:Rada při návrhu db tabulek

« kdy: 27. 06. 2021, 21:08:08 »

ORM fungují pro menší data, pro data, kde nikdy nebudete dělat hromadné operace. V opačném případě jsou s tím pekelné problémy, a to co ušetříte na programování, to 10x zaplatíte na supportu, tuningu, a řešení různých performance issue

coz je blbost, moderni ORM funguji transparentne, vite, jaky dotaz to vygeneruje a muzete vygenerovat temer cokoliv