Rada při návrhu db tabulek

Re:Rada při návrhu db tabulek
« Odpověď #120 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.


Re:Rada při návrhu db tabulek
« Odpověď #121 kdy: 27. 06. 2021, 21:34:41 »
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 ...").

Re:Rada při návrhu db tabulek
« Odpověď #122 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.

Re:Rada při návrhu db tabulek
« Odpověď #123 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

Re:Rada při návrhu db tabulek
« Odpověď #124 kdy: 27. 06. 2021, 21:40:59 »
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.

To jsme zase u jádra pudla. Třeba ty "pokročilejší validace" obvykle obnášejí to, co psal Pavel - čtení dat a iterace v kódu programu. Zrovna tyto operace chcete přenést do databáze, protože zrovna na nich je řádově efektivnější.

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

Čímž jsme se efektivně dostali na půdu čistého SQL a namapování dat do nějaké vyšší struktury.


Re:Rada při návrhu db tabulek
« Odpověď #125 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.

Re:Rada při návrhu db tabulek
« Odpověď #126 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?

Re:Rada při návrhu db tabulek
« Odpověď #127 kdy: 27. 06. 2021, 21:54:43 »
Čí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.

Re:Rada při návrhu db tabulek
« Odpověď #128 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.

Re:Rada při návrhu db tabulek
« Odpověď #129 kdy: 27. 06. 2021, 22:06:52 »
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.

Pokud nebudete počítat bitcoiny, tak drtivou většinu operací můžete bezproblémově počítat v databázi. Úzkým hrdlem jsou diskové operace, případně přístupy do RAM. CPU většinou u běžných OLTP aplikací se fláká. 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.

Re:Rada při návrhu db tabulek
« Odpověď #130 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.

Re:Rada při návrhu db tabulek
« Odpověď #131 kdy: 27. 06. 2021, 22:26:53 »
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.

Vstupy musíte validovat, ale konzistenci dat taky. To se nevylučuje.
Ale hovořil jste o složitější validaci - a pod tou si představuji např. to, že k validaci potřebuji ověřit data v jiných strukturách, abych mohl říct, že vkládaný vstup je v pořádku.

To určitě nezpůsobuje úzké hrdlo.

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.

Re:Rada při návrhu db tabulek
« Odpověď #132 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.
« Poslední změna: 27. 06. 2021, 22:36:04 od A.P.Hacker »

Re:Rada při návrhu db tabulek
« Odpověď #133 kdy: 27. 06. 2021, 22:35:37 »
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.

Kontrola na aplikační straně má tu nevýhodu, že se dá "snadno" obejít, zapomenout, ... db server side kontrolu vám nikdo neobejde. Jinak není na škodu mít kontroly implementované 2x - pro interaktivní práci různé validátory na klientovi, a pak na databázové straně, která vám garantují kvalitu dat.

Samozřejmě, že databáze je u databázových aplikací hrdlem - čekáte na disky, případně na zámky, ale to budete čekat tak jako tak. Když ale přidáte správně indexy, tak dnešní servery bezproblémově utáhnou desítky tisíc uživatelů. Před dvěma měsíci jsem pro jednoho zákazníka pomáhal doladit databázi, která měla něco kolem 200GB, a 10K současně pracujících uživatelů nevygenerovalo znatelnou zátěž na CPU. Po přidání správných indexů - trhnul jsem rekord - dotaz jsem zrychlil 10 000 krát.

Re:Rada při návrhu db tabulek
« Odpověď #134 kdy: 27. 06. 2021, 22:46:41 »
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.

Zkuste mi vysvětlit, v čem si myslíte, že může být aplikace efektivnější - třeba v tom případě více používaného fóra. Mně nenapadá nic, co bych dokázal udělat v aplikaci rychleji, než to přenést do databáze. Včetně označení uživatelem nepřečtených příspěkvů, včetně označení přečtených, ... (Pokud ovšem nezvolím, že to bude client-side logika, ale to asi není případ, o kterém hovoříme zde).